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Az alkalmazott tudományoknak mindig is vol- 
tak központi fellegvárai — olyan kutatóközpon- 
tok, melyben egyesültek az emberi és anyagi 
erőforrások egy adott technikai probléma meg- 
oldására és kifejlesztésére. Alkalmazott tudo- 
mányokról lévén szó, a legnagyobb központok általában nem 
állami támogatással működnek, hanem egy-egy vállalat üzleti 
célú fejlesztéseinek kutatási hátterét adják, így az informatikai 
újítások zöme is piaci szereplők, cégek által működtetett ku- 
tatóközpontokban lát napvilágot. 

Kályhának tekinthetjük az AT8.T Bell Laboratóriumot, ahol töb- 
bek közt a UNIX-ot is kifejlesztették, de innen jött a C nyelv, a cel- 
luláris távközlés, a T-1-es vonali adatátvitel, a tranzisztor és még 
néhány más Nobel díjas találmány is, ahogy ezt az utód Lucent 
Technologies reklámjában is olvashatjuk. A másik kályha természe- 
tesen a Xerox által működtetett PARC (Palo Alto Research Cen- 
ter), ahol nem kisebb dolgokat találtak ki, mint a grafikus fel- 
használói felület, a legördülő menük vagy maga az egér. Törté- 
nelmi már az a mindannyiunk számára közismert pillanat, amikor 
Steve Jobs és Bill Gates együtt látogatott el a PARC-ba, ahol egy 
magyar származású mérnök egy új megközelítésű kezelőfelület- 
tel ellátott operációs rendszer tesztváltozatát mutatta be nekik. 
Ez a magyar mérnök, Charles Simonyi azóta a Microsoft-nál dol- 
gozik már több, mint 25 éve - ahol szintén létrejött egy, az elő- 
zőekhez hasonló kutatóközpont, a Microsoft Research. Az MS 
Research kutatási eredményeinek egy részét közvetlenül is lát- 
hatjuk a Microsoft termékekben, (mint pl. az SOL Server English 
OXwery, a hangfelismerés az Office XP-ben), azonban a kutatások 
nagy része nem termékspecifikus. Egy, az MS Research-öt be- 
mutató előadáson engem nagyon meglepett, hogy Redmond- 
ban olyan, kifejezetten matematikai kutatások is folynak, mint 
például az ,utazó ügynök" néven ismert probléma megoldásá- 
nak keresése - azaz a feladatok lineáris időben való algoritmi- 
zálhatóságának kutatása. De ott van a misztikus , szándék ala- 
pú" programozás (intentional programming) kérdésköre is, ami- 
vel Charles Simonyi és kollégái már több, mint egy évtizede 
foglalkoznak. A kutatáshoz sok idő, és persze még több pénz 
kell - a Microsoft úgy tűnik, mindkettőt hosszú távon is bizto- 
sítani tudja. A fiúk lemennek a bányába, néha feljönnek leve- 
gőt venni, elmesélik hogy állnak a munkával - ha az eredmény 
nem megfelelő, visszaküldik őket. Egész addig, míg fel nem 
hozzák a mélyből azt a gyémántot, amit keresnek. 

Amikor a fiúk nemrég feljöttek, hoztak magukkal néhány dol- 
got, amiből idén április elejére egy kész termék lett: megjelent 
végre a SharePoint Portal Server 2001 (rövidítve SPS, korábbi 
kódnéven Tahoe - ebből is látszik, hogy a fiúk mivel töltik egyéb- 
ként szabadidejüket: mind Whistler, mind Tahoe egy-egy sípara- 
dicsom neve Washington államban, Redmondtól kicsit északra) . 
Mit is tud az SPS? Három fő funkciója az átfogó ismeretkezelés, 
a portálszolgáltatások és az elektronikus dokumentumkezelés. 
Az első, az ismeretkezelés kicsit fellengzősen hangzik, de épp 
ez az a terület, ahol a legtöbb MS Research kutatási eredmény 
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A fiúk 


a bányában... 
és a horgászok 


megtestesül - az SPS már-már mesterséges intelligenciához ha- 
sonló eszközök arzenálját vonultatja fel ahhoz, hogy uralni tud- 
juk a fájlszervereinken és egyéb információtároló alkalmazá- 
sainkban kialakult dokumentumkáoszt. 

A könyvtárban a könyvtáros a saját természetes intelligenciáját 
használva dönti el, hogy egy könyv milyen kategóriába kerül- 
jön. Az SPS-nek csak megmondjuk a kategóriákat, megmuta- 
tunk néhány dokumentumot, ami ebbe a kategóriába tartozik — 
az SPS pedig magától megtanulja, mi a kategória szabálya. Az 
összes többi dokumentumot (legyen az több ezer) indexelés 
után már önmaga fogja elhelyezni a megfelelő kategóriákba. 
Keresésnél szintén tartalom szerint, intelligensen elemzi az 
eredményeket, és aszerint adja vissza azokat, hogy valóban ar- 
ról szól-e az adott dokumentum, mint amit kerestünk (Nem pe- 
dig aszerint, hogy a főcímben, vagy alcímben szerepelt-e a kere- 
sett kifejezés...) Félelmetes. 

No és természetesen megvan az az előny, hogy ha kategória 
szerint keresünk, a kategóriarendszer nem alkot egy fix hie- 
rarchiát - tetszőlegesen választjuk meg, hogy milyen néze- 
tet akarunk látni. Egy dokumentum természetesen több ka- 
tegóriába is tartozhat. Az is jó lenne, ha azonnal kapnánk ér- 
tesítést, ha megjelenne egy új könyv, amiben mongúzok sze- 
repelnek. Az SPS ezt is tudja. 

Az SPS alapja az az univerzális adattároló motor, ami az 
Exchange 2000-et is hajtja: a Web Storage System (de az SPS 
teljesen független az Exchange-től, egyáltalán nem igényli a je- 
lenlétét). A portálszolgáltatásoknál a Digital Dashboard tech- 
nológia végre nemcsak egy SDK, hanem kész megoldás formá- 
jában jelenik meg. A dokumentumkezelési funkció hivatalos 
iratok kezelésében segíthet a verziókövetéssel, a dokumentu- 
mok hivatalos útjának munkafolyamatba szervezésével, a meg- 
felelő szerepkörök, jóváhagyási útvonalak elektronikus kezelé- 
sével. A portálszolgáltatással együtt a dokumentumkezelés tel- 
jesen önálló webes közzétételi rendszert alkothat (pl. vállalati 
intranet, vagy egy szerkesztőségi rendszer). 

A Microsoftnak persze nemcsak kitűnő bányászai vannak, ha- 
nem mellettük egy kisebb horgászegyesületet is fenntart. A 
horgászfiúk folyamatosan figyelik a vizet, és ha egy hal na- 
gyon ficánkol, kihalásszák. Nemrég egy NetIO Operations Ma- 
nager nevű halat fogtak. Az SPS még alig született meg, máris 
egyedül érezte magát: a horgászok így április végén fogtak ne- 
ki egy társat: a neve NCompass Labs Resolution 4.0. A kifogott 
halak a Microsoft-nál egy ideig hittanórára járnak, hogy meg- 
tanulják az új vallást, majd újra is keresztelik őket. 

Ebben a keresztségben az NCompass Resolution is új nevet kap 
majd, így ősszel mi már a Microsoft Content Management Server 
2001-gyel ismerkedhetünk meg. Bővül a .NET kiszolgálócsalád... 


Horváth Tamás 


Microsoft Magyarország 
tamash Emicrosoft.com 
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Service 
Pack 2 


Windows 2000 Service Pack 2 

Megjelent a Windows 2000 Service Pack 2 [1], amely a biz- 

tonsági hibajavítások mellett néhány újdonságot is tartalmaz: 

"0 beállítható kompatibilitási szintek Windows 95-höz és 
Windows NT 4 SP5-höz 

9 128 bites biztonsági alrendszer (a telepítés után ez a 
rész már nem távolítható el) 

"A új, külön letölthető telepítőeszközök (deploy.cab) és 
Support Tools 

2 UATA-100 eszközmeghajtók 

Az angol nyelvű Windows 2000-re telepíthető javítócsomag 

a NetAcademia kiszolgálón is megtalálható [2]. 


Nem titkos, de nem nyílt a Windows forráskódja 

A Microsoft azt tervezi, hogy különböző feltételek mellett, de 
válogatott partnereinek (szoftver-, és hardvergyártók, egyete- 
mek számára) elérhetővé teszi a Windows és más szoftverek 
kódjait, persze megfelelő jogi korlátozások és különböző li- 
cencfeltételek mellett [3]. A Microsoft hangoztatja, hogy ez 
a kezdeményezés (, shared-source" [4]) nem egyezik meg a 
manapság divatos open source megoldásokkal. 


Licencelési tájékoztató magyarul 

Számos új licenctípus (köztük olyan frissítési opcióval, 
amely éves díjazású, a CAL árának 25-3099-ába kerül, és ma- 
gába foglalja a mindenkori legfrissebb verzió, a korábbi ver- 
ziók, valamint a terméktámogatás használatának jogát) be- 
jelentésével egyidőben megjelent a magyar nyelvű Licence- 
lési tájékoztató, amely PDF és MSReader formátumban le- 
tölthető az [5] címről. 


HÍREK... HÍREK...HÍREK 





Microsoft Content Management Server 2001 

Az Olvasónak talán ismeretlen a fenti cím; talán kicsit furcsa 
is, hogy miközben a hasonló célokkal készült SharePoint Por- 
tal Server szinte még meg sem jelent, a Microsoft máris va- 
lami újabb megoldással jelentkezik. Mégis: miután nyilvánva- 
lóvá vált, hogy a webtartalom kezelésére komplett és haté- 
kony eszközökre van szükség, a Microsoft felvásárolta az 
NCompass nevezetű céget [6]. A cég webtartalom-menedzs- 
ment eszköze, az NCompass Resolution 4.0 [7] már egy jó 
ideje nem kis cégeknél bizonyít. Az SOL 2000 alapon futó, a 
Commerce Server 2000-rel, a BizTalk Server 2000-rel, vala- 
mint a SharePoint Portal Server-rel már most is együttműkö- 
dő alkalmazás épp a fentiek miatt nagyon könnyen beilleszt- 
hető a .NET infrastruktúrába: így lesz belőle majdan (várha- 
tóan 2001 őszén) Microsoft Content Management Server. A 
[8] címen rövid regisztráció után megtekinthető Flash demo 
alapján igéretes kezdeményezésnek nézünk elébe. 


[1] http://www.microsoft.com/windows2000/ 

4 downloads/servicepacks/sp2/default.asp 

[2] http://download.netacademia.net/servpack/w2ksp2/ 
[3] http://www.microsoft.com/presspass/features/ 

4, 2001/mayO1/05-O3csm.asp 

[4] http://www.microsoft.com/Business/ 

4 Licensing/SharedSource/ 

[5] http://www.microsoft.com/hun/jogtisztasag/ 

[6] http://www.microsoft.com/presspass/press/2001/ 
4 AprO1/04-3ONCompassPR.asp 

[7] http://www.ncompass.com/ 

[8] http://www.ncompass.com/products/ 

4 ncompassiresolution/ product--tour.htm 
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Nagy csomag, kis cégeknek 

Most induló cikksorozatunkban bemutatjuk a Microsoft Small 
Business Server 2000 [1] programcsaládot, amely -— nyugod- 
tan állíthatjuk - a legjobb és legolcsóbb MS megoldás lehet 
a kisebb cégek informatikai hátterének biztosítására. Szinte 
mindent tud, amit a ,nagyok" (értsd a BackOffice család), 
persze itt-ott korlátokba ütközünk. Ha a korlátok már nagyon 
szorítanának, megvan a módja, hogy fájdalommentesen fel- 
oldjuk azokat: a Small Business Server 2000 (a továbbiakban 
egyszerűen csak SBS 2000) később frissíthető lesz a korlátok 
nélkül használható BackOffice kiszolgálócsaládra. 


Mi van a csomagban? 

Az SBS 2000 a következő komponenseket tartalmazza: 

"0 Windows 2000 Server - fájl- és nyomtatáskiszolgáló, 
webkiszolgáló (IIS), terminál-szolgáltatások 

Exchange 2000 Server - csoportmunka, internetes 
levelezés 

) Internet Security and Acceleration (ISA) Server 2000 

- tűzfal és gyorsítótár, virtuális magánhálózatok és 
RAS szolgáltatás 

SOL Server 2000 

megosztott faxszolgáltatás 

megosztott modemszolgáltatás 

Microsoft Health Monitor 2.1 - a kiszolgáló és az alkal- 
mazások teljesítményének, paramétereinek ellenőrzé- 
se, naplózása 

"0 FrontPage 2000 és Outlook 2000 kliensalkalmazások 

- mindez (tényleg) hihetetlen jó áron. Az éremnek persze két 
oldala van, a később említendő korlátozások mellett a Small 
Business Server jellegzetessége, hogy az összes kiszolgálóal- 
kalmazás ugyanazon a számítógépen fut - a kis cégnek általá- 
ban nincs is szüksége ennél többre. Mire a kiszolgálók erőfor- 
rásigénye átlépi az egy gépen biztosítható határt, a vállalat 
valószínűleg éppen kinövi a Small Business Server-t. Az SBS 
2000 erőforrásigénye a kiszolgálón a következő: 


mm 
A 


a 
vm 


minimális ajánlott 


PII 300 PIII 500 


merevlemez 

800x600, 1024x768 

256 szín (az adminisztrációs 
eszközöknek) 

Hálózati csatoló (NIC) 

Faxmegosztáshoz: CLASS-1 faxmodem 

Proxy, RAS, modem sharing: 4- 1 modem 


processzor 


Migigá aj 


Amikor a Performance Monitor (vagy a Health Monitor) jelzi 
a processzor, a memória vagy a lemezegység túlterhelését 
(bizonyos számlálók ilyenkor az égbe szöknek), itt az ideje, 
hogy a zsebünkbe nyúljunk, és bővítsük a gépet. Általánosan 
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Server 2000 
(I. rész) 


igaz az a nézet, hogy minél több szolgáltatást használunk, 
minél több adatot tárolunk, minél több forgalmat generálunk, 
annál nagyobb processzorteljesítményre, memóriára és annál 
jobb, nagyobb és gyorsabb háttértárra lesz szükségünk. A fen- 
ti táblázat rovatait tehát fenntartásokkal kezeljük; az ese- 
tünkben érvényes erőforrásigényt az általunk telepített alkal- 
mazások és a felhasználók száma határozza majd meg. 


Mitől Small Business a Small Business? 

Az SBS 2000 jól definiálható korlátozásokat tartalmaz a 
BackoOffice-hoz képest, ez különbözteti meg a nagytestvértől. 
Az első korlátozással már találkoztunk: bár a tartományba to- 
vábbi tartományvezérlőket telepíthetünk (persze külön Win- 
dows 2000 Server licenccel) , az összes SBS kiszolgálóalkalma- 
zásnak ugyanazon a gépen kell futnia. Apropó, tartomány: az 
SBS 2000 nem teszi lehetővé, hogy tartományok közötti meg- 
bízotti kapcsolatokat hozzunk létre. Windows 2000 környezet- 
ben ez azt jelenti, hogy az SBS tartományunk nem lehet más 
tartományi fa, netán erdő része. Nem, a mi kis SBS tartomá- 
nyunk a saját erdejében, az erdőt alkotó egyetlen fa egyetlen 
ágának csúcsán csücsül. A fától csak akkor láthatjuk meg az 
erdőt, ha továbblépünk a BackOffice felé. 

Az SBS részeként szállított Exchange 2000 Server-ben nem 
hozhatunk létre telephelyek közötti csatolókat, úgynevezett 
site connector-t. Ezzel és az előző, tartományra vonatkozó 
korlátozással a Microsoft azt szeretné elérni, hogy az SBS-t ne 
lehessen hatékonyan használni nagyobb vállalatok telephe- 
lyein. Ha az anyacég a telephelyre költségtakarékossági okok- 
ból SBS-t telepít, hát tegye, de akkor le kell mondani a közös 
tartományi adatbázisról és a központilag felügyelt és együtt- 
működő levelezésről és csoportmunka-kiszolgálóról. Az Ex- 
change , cserében" tartalmaz viszont egy POP3 Connector-t, 
aminek segítségével az Exchange képes a külső Internetszol- 
gáltatónál fenntartott privát postaládáinkból a céges mailbo- 
xunkba időnként letöltögetni a leveleinket. Ez a szolgáltatás 
tipikusan azoknak a cégeknek készült, akik egy ISDN, netán 
hagyományos telefonvonal segítségével érik el az Internetet, 
lassú, és elsősorban nem állandó kapcsolaton keresztül. 


50 felhasználó 

Az SBS 2000 legfeljebb ötven felhasználó/munkaállomás hasz- 
nálatát engedélyezi. Miközben az Active Directory-ba végte- 
len számú felhasználót (és postaládát is) felvehetünk, az SBS 
csak korlátozott számú egyidejű ügyfélkapcsolatot tesz lehe- 
tővé, és ötven a maximális száma a létrehozható ügyfélkonfi- 
gurációknak is (felhasználós:-munkaállomás páros). 


A telepítés 

Az elődökhöz képest a telepítés kicsit megváltozott. Az SBS 
továbbra is közös programcsomagként telepíthető, azonban 
az operációs rendszer telepítését elválasztották a kiszolgá- 
lóalkalmazások telepítésétől. Ez nem jelenti azt, hogy az 
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SBS telepítőkészlet nem tartalmazza a Windows 2000 Ser- 
ver-t, sőt, az SBS-nek muszály a saját CD-jéről W2K fészket 
rakni. Mindössze a telepítés menete bonyolódik egy kissé. 
A Windows 2000 Server telepítése a szokásos módon törté- 
nik, az egyetlen különbség talán csak az, hogy a kódtáb- 
lák, nyelvi támogatás beállítása után a komponensek kö- 
zött felesleges matatnunk, az SBS telepítő a későbbiek so- 
rán úgyis feltelepíti a hiányzó összetevőket. Ugyanez igaz 
a hálózati kapcsolatra is, a hálózati kártya beállításait - 
hacsak nincs rá a telepítés előtt szükségünk - hagyjuk 
alapértelmezésen. Miután a Windows 2000 Server elké- 
szült, telepítsük a szükséges eszközmeghajtókat (nyomta- 
tó, videókártya, stb.) , majd az SBS CD-ről indítsuk el az SBS 
telepítőt. A főoldalon kattintsunk a Set Up Small Business 
Server linkre, erre elindul a telepítést segítő varázsló. 





EJ am 





a Az SBS telepítő varázsló figyelmeztet, ha hiányossá- 
gokat tapasztal a rendszerben 


A továbbkattintás után megjelenő ablakban a varázsló figyel- 
meztet, ha a rendszer paraméterei nem érik el a minimális, 
illetve az ajánlott szintet. Ha a minimális korlátokat sem si- 
kerül hiánytalanul teljesítenünk, a telepítés nem folytatódik. 
Érdekesség, hogy az elődökkel ellentétben most a modem 
nem, a hálózati kártya viszont feltétel az SBS telepítéséhez. 
A telepítés első lépése a Windows 2000 Server felkészítése az 
apaságra. Ennek érdekében települ majd a terminálszolgálta- 
tás, valamint az Active Directory. Ne lepődjünk meg tehát, 
ha a telepítő varázsló az informatív adatok mellett címtárral, 
tartománnyal kapcsolatos kérdéseket is feltesz majd. 





(ta TEJ eme 





0 Az SBS és a kliensalkalmazások más-más licenckul- 
csot használnak. A második ábrán az automatikus beje- 
lentkezés adatai láthatók 


Mindenekelőtt azonban meg kell adnunk néhány más jelle- 
gű adatot: fogadjuk el a licencszerződést, írjuk be saját, 
vagy cégünk adatait, majd írjuk be illetve ellenőrizzük a li- 
cenckulcsokat (az SBS önmaga és a kliensalkalmazások — MS 
Outlook - más-más kulcsot használnak). A telepítés során 
szükség lehet a rendszer újraindítására. A fenti ábra jobb 
oldalán látható ablakban a varázsló felajánlja segítségét: 
ha megadjuk a rendszergazda jelszavát, automatikusan be- 
jelentkezik majd, és ott folytatja a telepítést, ahol abba- 
hagyta; ellenkező esetben nekünk magunknak kell majd 
minden újraindítás után bejelentkeznünk a rendszerbe. 
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o Hálózati konfiguráció — nincs túlbonyolítva 


A következő érdemleges helyszín a hálózati beállítások panel- 
ja: az SBS telepítő minden hálózati kártyát letilt, és az egyiken 
saját alhálózatot hoz létre. A létrehozott alhálózat a privát 
192.168.x.x címtartományba esik, bár ezt a telepítőben testre- 
szabhatjuk. Általában érvényes az a tétel, hogy ahol az SBS-re 
van szükség, ott nagy valószínűség szerint teljesen mindegy, 
hogy a hálózat milyen IP címet és alhálózati maszkot visel, 
ezért érdemes elfogadni a telepítő alapértelmezését. A telepí- 
tés után ne felejtsük el újra engedélyezni a hálózati kártyákat 
(bár erre a To Do List külön lépésben fel is szólít majd). 


Néhány szó a SmallBusiness Kft-ről: cikksorozatunk 
áldozati báránya egy tipikus mai kis cég. A jelenlegi, 
egyértelműen javításra szoruló munkamenet a követ- 
kező: a cég néhány tíz alkalmazottja egy irodaház 5. 
emeletén, öt-hat szobában dolgozik. A belső hálózat 
peer-to-peer alapú, az adatokat mindenki a saját (ve- 
gyesen Windows 98, NT illetve Windows 2000 Professi- 
onal) számítógépén tárolja, szükség esetén bizonyos 
könyvtárakat megosztva biztosítja a többieknek a hoz- 
záférést. A cég kifejezetten informatikus szakembert 
nem tart, inkább szükség esetén igénybe veszi egy MS 
megoldásszállító segítségét. 

A cégnek egy ismert internetszolgáltatónál van néhány 
postaládája (egy a cégnek, egy-egy a fontosabb alkalma- 
zottaknak). Az internetszolgáltató üzemelteti továbbá 
a cég internetes honlapját is. A cég internetelérését a 
kivételezett számítógépekre aggatott modemek bizto- 
sítják, ugyancsak az internetszolgáltatónál fizetett hoz- 
záférések segítségével. 

A közös fax a titkárnő irodájában ontja a papírt, a bejö- 
vő faxokat igény szerint ő fénymásolja és osztja szét a 
címzetteknek. Ha valaki faxot szeretne küldeni, kinyom- 
tatja, majd a faxhoz ballag, és elküldi (esetleg megkéri 
a titkárnőt, hogy küldje el ő). A könyvelői csoport szá- 
mítógépein található modemek a banki ügyfélterminál 
használatához szükségesek. 


Az SBS tartomány 

Az SBS tartomány (ami nem más, mint egy Windows doma- 
in) megválasztásánál kicsit óvatosabbnak kell lennünk. 
Nemcsak azért, mert a rendszer telepítése után a tarto- 
mány nevének megváltoztatására már nincs mód, hanem 
azért is, mert a Windows 2000 tartomány összenőtt az in- 
ternetes névfeloldási hierarchiával (DNS). Abban a pilla- 
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natban, amikor a cégünk az internetes világban is meg szeret- 
ne jelenni, saját tartománynevet kell majd regisztrálnia (vagy 
talán már meg is tette). A Windows 2000 tartomány adatai is 
a DNS-ben találhatók, ez az információ viszont nem feltétlenül 
egyeztethető össze a külvilág által ismert tartománnyal, 
ráadásul sok esetben nem szükséges, mitöbb nem biztonságos, 
ha a tartományi információk a külvilág tudomására jutnak. 
Esetünkben a következőről van szó: cégünk, a SmallBusiness 
Kft. régebben létrehozott weblapját egy internetszolgáltató sa- 
ját szerverén üzemelteti, a www.smallbusiness.hu cím alatt. Eh- 
hez a címhez tartozik egy DNS zóna, ami a smallbusiness.hu tar- 
tomány bejegyzéseit tartalmazza (névkiszolgálók, levelező kiszol- 
gálók, további tagok, pl. a www is). Mindez tőlünk függetlenül, 
az internetszolgáltató segítségével, a nagyvilágban működik. 
Amikor az SBS kiszolgálót telepítjük, választanunk kell egy 
tartománynevet. Ha egyszerűen a smallbusiness.hu nevet 
választjuk, a tartomány adatai a smallbusiness.hu DNS zó- 
nába kerülnek bele, a zónát persze nem az internetszolgál- 
tató DNS kiszolgálója, hanem az SBS saját DNS szolgáltatá- 
sa kezeli. Ilyenkor két rossz megoldás közül választhatunk: 
b ,Behozzuk" a DNS zónát az internetszolgáltatótól - 
ekkor a világ felől érkező összes kérés az SBS kiszolgálóra 
esik be, terhelve a vállalati vonalat. Arról nem is beszélve, 
hogy ehhez állandó hálózati kapcsolat és fix IP cím szük- 
séges (tipikusan bérelt vonal vagy hasonló megoldás). 
Kivisszük" a Windows tartomány adatait a szolgáltató 
DNS kiszolgálójára - ekkor a cégen belüli összes tarto- 
mányi DNS lekérdezés az internetszolgáltatón keresztül 
fog zajlani, ami ugyancsak terheli a céges vonalat. (Ha 
nem fix a hálózati kapcsolat, akkor az állandó lekérdezé- 
sek miatt majd kvázi az lesz :-) ). Ráadásul az internet- 
szolgáltatók által üzemeltetett DNS kiszolgálók nem biz- 
tos, hogy képesek a W2K által elvárt működésre (dinami- 
kus rekordfrissítés, SRV rekordok, stb.). 

Bármelyik megoldást is választanánk, még ott lenne az a 
probléma, hogy a belső hálózatunk adatai (belső IP címek, 
a belső felépítésre utaló adatok, stb.) a replikáció során 
gyakorlatilag a világ összes DNS kiszolgálójára eljuthatná- 
nak. Ezek az adatok a tartományi felhasználókon kívül egy 
valakit érdekelhetnek: a fekete kalapos hackert, akinek 
egyetlen célja, hogy tönkretegye a konkurrenciát. 


b 


Mi a megoldás? 

Legjobban tesszük, ha az SBS tartományt a cég domain ne- 
ve alatti aldomainként hozzuk létre, például így: 
sbsdomain.smallbusiness.hu 

A tartományi adatok ekkor nem közvetlenül a smallbusiness.hu 
alá kerülnek, hanem egy szinttel , lejjebb", az 
sbsdomain.smallbusiness.hu alá. 

Hogy mi ebben a jó? A kulcs a delegáció, hölgyeim és uraim. 
A DNS-nek ugyanis jó alaptulajdonsága, hogy az óriási név- 
tér egyes részeit más-más DNS kiszolgáló tartja karban. 
(Még jó, különben nem is lenne képes működni.) Amikor egy 
DNS zóna egy alzónáját valaki másnak , adjuk", ezt nevez- 
zük delegációnak. Ilyenkor a mi DNS zónánkban az alzóná- 
nál egyetlen NS bejegyzés szerepel: ,ha erről az alzónáról 
bármit tudni akarsz, őt kérdezd!". 

Esetünkben tehát a smallbusiness.hu zóna marad az inter- 
netszolgáltatónál, ebben a zónában található az sbsdomain. 
smallbusiness.hu bejegyzés, ami egyetlen delegációs re- 
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kordban merül ki, és az SBS kiszolgálónkra mutat. Ha vala- 
ki az sbsdomain.smallbusiness.hu-ról érdeklődik, az SBS ki- 
szolgálóhoz fordul majd, más kérdés, hogy a kiszolgáló vá- 
laszol-e neki (természetesen csak akkor, ha az illető tarto- 
mányi tag, azaz van köze az adatokhoz). Így már minden 
klappol: ami bent kell, az bennmarad, ami kint kell, az 
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5 A tartománynév kiválasztásakor legyünk óvatosak és 
gondolkodjunk néhány évre előre! 


A tartomány NETBIOS neve (ami a régebbi klienseknek kell- 
het) alapértelmezésben a tartomány DNS nevének első részé- 
ből készül, ebből a szempontból tehát az altartományként 
való létrehozás nem jelent változást; arról nem is beszélve, 
hogy mint az az ábrán is látható, a NETBIOS tartománynév 
az igazi tartománynévtől teljesen függetlenül is megadható. 


A telepítés további menete 

A tartománynév kiizzadása után meg kell adnunk a Directo- 
ry Services Restore Mode rendszergazdai jelszavát (lásd 
Windows 2000 Server alapismeretek: a címtár visszaállításá- 
hoz használatos boot üzemmódhoz szükséges bejelentkezési 
jelszó). Ezután áttekinthetjük a telepítés ezen szakaszának 
összefoglalóját (hálózati és tartományi konfiguráció, termi- 
nálszolgáltatás telepítése és hálózati azonosító adatok beál- 
lítása), majd gombnyomásra megkezdődik a Nagy Reszelés 
(mindenféle perverz felhang nélkül értendő!) első szakasza. 





az ábrán is látható, ,, titokban" még a DCPROMO is lefut... 


A telepítés befejezése után a kiszolgáló újraindítása következik. 
Az újraindulás után a számítógép már mint tartományvezérlő 
működik, és kezdődhet a valódi SBS komponensek telepítése. 


A telepítendő komponensek kiválasztása 

A számítógép újraindulása után - ha kell, segítsünk a beje- 
lentkezéskor - ismét elindul az SBS telepítő varázsló, és el- 
jutunk a komponensek kiválasztására szolgáló képernyőhöz. 
Tüzetesen vegyük szemügyre a tartalmát: 
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5 A telepítendő SBS komponensek kiválasztása 


Vegyük észre az Install és a Maintenance felirat melletti kis -- 
jeleket! Ez azt jelenti, hogy a csoport alatt további beállítások 
találhatók (nyissuk ki egyenként a csoportokat a nagy 3- jelekre 
kattintva) . Ellenkező esetben könnyen előfordulhat, hogy a fő- 
csoportra kattintva például azt hisszük, hogy telepítettük az 
SOL Server-t, miközben összesen a dokumentációt sikerült fel- 
másolnunk a kiszolgálóra. Az egyes komponensek kiválasztása- 
kor az ablak alsó részében látható a telepítési útvonal, ami 
szükség esetén megváltoztatható. A továbbkattintás után a ki- 
választott komponensek alapvető beállításait kell megadnunk. 





9 Az ISA Server beállításai 


Ha például az ISA Server-t kiválasztottuk a telepítendő kompo- 
nensek listájából, most meg kell adnunk, hogy mekkora gyorsí- 
tótárat szeretnénk, és hogy hova akarjuk azt helyezni. A gyor- 
sítótár csak NTFS partícióra kerülhet, és az alapértelmezett 100 
MB kezdésnek megfelelő lesz. Ezek az értékek a későbbiek so- 
rán természetesen módosíthatók. Az ISA Server másik fontos 
beállítandó paramétere a helyi IP címeket tartalmazó táblázat, 
a LAT (Local Address Table). Az ISA ennek alapján tudja ugyan- 
is, hogy ki az, aki a tűzfalon belül, illetve kívül tartózkodik 
(függetlenül attól, hogy melyik hálózati kártyán csatlakozik a 
géphez). A LAT összeállításában segít a varázsló: mielőtt kézzel 
szerkesztgetnénk a címtartományokat, kiválaszthatjuk, hogy 
szeretnénk-e a privát címeket, illetve a kiválasztott belső háló- 
zati kártyánkról leolvasható alhálózat címeit felvenni a LAT-ba. 
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9 Az SOL Server beállításai. Ha ezekkel az ablakokkal a 
telepítés során nem találkozunk, kezdjünk gyanakodni! 
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Az SOL Server kiválasztása nem könnyű feladat, ugyanis a tele- 
pítő az SOL Server gyökerének kiválasztása során hajlamos az 
alatta található dolgokat üresen hagyni. Ennek az az eredmé- 
nye, hogy SOL Server nélkül települ fel az SBS. Bár az SOL Ser- 
ver-t később is hozzáadhatjuk, de az külön macera - figyeljünk 
inkább oda, ne hagyjuk magunkat becsapni. Az SOL Server elő- 
zetes konfigurációja 4-5 dialógusablakon keresztül vezet (ebből 
kettő látható fentebb) , ezek hiányát nehéz nem észrevenni. Az 
ábra bal oldalán található dialógusablak az adatbázis alapértel- 
mezett kódtáblájának kiválasztására szolgál (hogy itt mit állí- 
tunk be, az függ az SOL Server későbbi felhasználásának módjá- 
tól); a jobb oldalon pedig az SOL Server eléréséhez használha- 
tó metódusokat állíthatjuk be (például a TCP portot). Ezután 
még meg kell adnunk az SOL szolgáltatás futtatásához használt 
felhasználói fiókot és az alapértelmezett adatbázis helyét is. 





0 Az alapértelmezett mappák helye 


A telepítő utolsó érdemleges kérdése az alapértelmezett 

mappák helyére vonatkozik: 

"B User Shared Folders: a felhasználók saját mappáinak 
gyökérkönyvtára 

"2 Company Shared Folders: a felhasználók (illetve a cég) 
közös mappája 

"b Client Applications Location: a kliensalkalmazások te- 
lepítőkészleteinek helye 

"8 Fax Archive Root Directory: a faxszolgáltatás archívu- 
mának gyökérkönyvtára 

Az adatok megadása után elkezdődik a mintegy másfél órás 

telepítés, aminek során sorra adagoljuk majd a CD-ket a te- 

lepítőnek. A telepítés végén - néhány újraindítás után - 

megjelenik a To Do List feliratú ablak, ami a kiszolgáló első 

munkába állásakor elvégzendő feladatokat tartalmazza szép 

sorjában - a következő hónapban innen... 


Folytatjuk... 


Fülöp Miklós 
mick netacademia.net 
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Whistler Server Beta 2 újdonságok 

Az áprilisi tech.net számban Fóti Marcell tollából már olvas- 
hattunk némi előzetest a Whistler-ről. Most szintén csak sze- 
mezgetős jelleggel mutatnék be néhány újdonságot - ne fe- 
ledjük, a termék még csak Beta 2 állapotban van, a végleges 
funkciókészlet még nincs rögzítve, ezért előfordulhat, hogy 
egy bétában meglévő funkció nem lesz benne a végleges ter- 
mékben (ezt már a Windows 2000-nél is tapasztalhattuk) . 

A munkaállomás család végleges neve Windows XP, erre hi- 
vatalos megjelenési dátumot is bejelentett már a Microsoft: 
2001. október 25. (a kód természetesen már hamarabb, au- 
gusztus végén lezárul - október végére lehet várni a magyar 
nyelvű változat elkészültét is). 

A kiszolgálócsalád ennél később fog megjelenni, egyelőre 
nincs hivatalos dátum. Bár a Microsoft április végén egy sajtó- 
közleményben bejelentette a Windows 2002 Server nevet, ezt 
később visszavonta - egyelőre tehát nincs végleges döntés, 
így csak kódnéven, Whistler Server-ként hívjuk a terméket. 


Internet Information Service 6.0 

A Whistler Server az IIS új, 6.0-ás verziójával jelenik meg, 
amely jelentős architekturális változásokat tartalmaz. 

Az IIS 5.0 alatt az alkalmazások készítésénél döntenünk kellett 
az ,in-process" és az ,out-of-process" (00P) futtatás között. 







DLLHOST.EXE 





INETINFO.EXE 





DLLHOST.EXE 


DLLHOST.EXE 
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IIS 6.0 - Dedikált alkalmazásmód 

Az IIS 6.0 ún. dedikált alkalmazásmódot használ, ahol a 
felhasználói webalkalmazások kódja teljesen izolált környe- 
zetben fut, az IIS 5.0 out-of-process futtatási módjának 
stabilitásával, de annak teljesítménykorlátai nélkül. 





Felhasználói mód 





Kernel mód 
6 IIS 6.0 architektúra - dedikált alkalmazásmódban 


Az IIS 6.0 új architektúrájában az alapvető webkiszolgáló 
funkciók, a kérések, a gyorsítótár, a konfiguráció kezelése 
és a webalkalmazások felügyelete teljesen elkülönül a kül- 
ső, felhasználó által futtatott webalkalmazásoktól. Ezek a 
központi webkiszolgáló feladatok az új HTTP.SYS kernelmó- 
dú meghajtóban és az új Web Administration Service (WAS) 
felügyeleti modulban valósulnak meg. A külső, felhasználói 
alkalmazások egy ettől teljesen elszigetelt (00P) futtató 
környezetet kapnak, egy-egy saját mini-webkiszolgálóval 
(dllhost, ISAPI szűrők, ISAPI bővítmények) együtt - egy 
ilyen elkülönített webalkalmazás neve , worker process". Az 
izolált mini-webszerver környezetben az egyes alkalmazások 
egymástól függetlenül leállíthatók, újraindíthatók, debugol- 
hatók - az egyes worker processzek a LocalSystem fióknál 


FINKESÁRI WinSock 2.0 alacsonyabb jogosultsági szinttel rendelkező fiók nevében is 
SZESZ EL ÉTÖSSEE Z E EE EEES ÉS j--—-——- rt futtathatók, ami tovább növeli a megbízhatóságot. A webal- 
al. TCP/IP kalmazások ún. alkalmazás pool-okba csoportosíthatók, mely 
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Az in-processz kifejezés azt jelenti, hogy az alkalmazás egy 
szálként (thread) az INETINFO.EXE processz memóriaterüle- 
tén belül fut. Ennek előnye az, ami egyébként a szálak 
használatának az előnye: a szálak között gyors a kommuni- 
káció és a környezetváltás (context switching) . Hátránya vi- 
szont, hogy az alkalmazás hibája a teljes webkiszolgáló pro- 
cesszt magával ránthatja. 

Épp ezért a Microsoft is az 00OP futtatási módot ajánlja, azon- 
ban sokan mégis in-processz írják az alkalmazásaikat, mert az 
00P-nél csökken a teljesítmény, a felhasználói módú INETIN- 
FO és az egyes alkalmazások közötti inter-processz kommuni- 
káció és az egyes processzek közötti környezetváltások miatt. 
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az IIS 6.0 felügyeleti egysége: egy pool tartalma lehet egyet- 
len worker processz is, lehet webalkalmazások csoportja, 
vagy akár több webhely (több névtér!) is. 


IIS 6.0 - Kernelmódú webgyorsítótár 

A változás középpontja (mint az a fenti ábrán is látszik) a 
kernel módú HTTP.SYS meghajtó. Az IIS 5.0 a beérkező ké- 
réseket az INETINFO-ban, felhasználói módban figyeli - a 
TCP/IP stack-et pedig a Winsock interfészen keresztül éri 
el. A Winsock gyors, nincs vele semmi baj, de mégiscsak 
felhasználói módban van, és egyébként is egy általános há- 
lózati interfész. Az IIS 6.0-ban a HTTP.SYS közvetlenül az 
IP stack tetején csücsül, a beállított IP/port kombinációkat 
figyelve fogadja a kapcsolatfelvételi kéréseket, Winsock 
nélkül. Ennek előnye az, hogy a bejövő kérés nem a koráb- 
bi IP stack - Winsock - INETINFO - webalkalmazás utat jár- 
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ja be, hanem a jóval rövidebb IP stack - HTTP.SYS - web- 
alkalmazás utat (ami egy processzel, és két felhasználói mó- 
dú környezetváltással rövidebb) . 

A HTTP.SYS az egyes webalkalmazásokhoz érkező kéréseket 
sorba állítja, minden alkalmazás pool-hoz önálló puffert 
kezel, melyek hossza alkalmazásonként korlátozható - ha 
a beérkező, sorba állított kérések száma a pufferben eléri 
a maximumot az adott alkalmazáshoz, HTTP 503 hibaüze- 
netet küld vissza a HTTP.SYS - de csak az adott alkalmazás 
pool-hoz érkező kérésekre. 

Az alkalmazás pool-ok függetlenítése tehát már a kérések ke- 
zelésénél megtörténik. A kérések kezelésének központosítá- 
sával a sávszélesség korlátozása is jobban megoldható: a 
HTTP.SYS párhuzamosan tudja kiszolgálni a kéréseket a pool- 
okra meghatározott sávszélességkorlátokkal, szemben az IIS 
5.0 soros megoldásával (egy kérés innen, kettő onnan...) 

A HTTP.SYS másik nagy előnye a kernel módú webgyorsító- 
tár kialakítása a HTTP válaszokhoz, hiszen találat esetén 
egy választ közvetlen kernelmódból, környezetváltás nél- 
kül, azonnal visszaadhat (ez magyarul egy kb. kétszeres 
szorzó a teljesítményben). Ez a gyorsítótár nemcsak stati- 
kus, hanem dinamikus válaszokra (lapokra) is vonatkozik! 
Az újdonság az ún. Universal Resource Identifier (URI) 
HTTP response cache módszer. Ennek lényege, hogy a 
HTTP.SYS nem kényszerít egyetlen központi gyorsítótár sza- 
bályrendszert az összes alkalmazásra - az egyes alkalmazás 
pool-ok mondhatják meg önállóan, külön-külön (progra- 
mozható felületen keresztül) a HTTP.SYS-nek, hogy a saját 
HTTP válaszaikra milyen gyorsítótár kezelést használjon (ez 
nyilván főleg a dinamikus válaszok kezelésénél fontos). 


IIS 6.0 - Webalkalmazás felügyelet 

A Web Administration Service (WAS) egy új monitorozó 
funkció az IIS 6.0-ban, mely a webkiszolgáló részeként fut, 
külön processzként, felhasználói módban, szintén elkülönít- 
ve a külső webalkalmazásoktól. Dedikált módban a WAS 
feladata rendszeres időközönként ,megpingetni" az egyes 
worker processzeket. A , ping" itt nem IP alapú ICMP echo 
üzenet, hanem egy processzek közötti kommunikációs csa- 
tornán életjel lekérdezése az egyes worker processzektől. Ha 
egy worker processz nem válaszol egy ilyen oldalbalökésre, 
a WAS terminálja, és egy új példányt indít belőle. Mivel a 
kérések kezelése a HTTP.SYS-ben, és nem a worker processz- 
ben (tehát magában a webalkalmazásban) történik, a 
HTTP.SYS a processz terminálása után is fogadja az adott al- 
kalmazáshoz érkező kéréseket, puffereli, majd amikor a WAS 
elindított a hibás processz helyett egy új példányt, annak 
adja tovább őket. A böngésző előtt ülő felhasználó tehát 
semmit nem lát abból, ha egy webalkalmazás meghal, csak 
kicsit később kapja meg a választ (de nem kap HTTP 503-at). 
Térjünk vissza a WAS-hoz: ez a szervíz nemcsak monitoroz- 
Za a worker processzeket, hanem az életciklusukat is képes 
felügyelni: a Demand Start és az Idle time-out funkciókkal 
lehetővé teszi azt is, hogy egy nagy webalkalmazás egy- 
egy rész-processze csak akkor foglaljon erőforrásokat, ha 
azt valóban használják. 

Demand Start használatakor az adott worker processzt csak 
akkor hozza létre a webkiszolgáló, amikor a legelső kérés 
beesik a hozzá tartozó sorba a HTTP.SYS-ben. A WAS-ban 
minden egyes worker processzre meghatározható egy idő- 
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tartam - ha ezen ideig nem használja senki a worker pro- 
cesszt (idle állapotban van), a WAS automatikusan termi- 
nálja azt. Ha ezután érkezik HTTP kérés hozzá, újra létre fog 
jönni egy példány (de közben nem foglalta a memóriát!) . 


IIS 6.0 - Webkertek 

A Windows 2000-nél már meg kellett ismerkednünk néhány 
mezőgazdasági fogalommal, mint pl. a kiszolgálófarmok és 
fürtök. A Whistler-beli IIS 6.0 ezt tovább bővíti a Webkertek 
(Web Gardens) bevezetésével. A Web Garden egy olyan alkal- 
mazás pool, amelyben több, de teljesen azonos funkciójú 
worker processz fut, melyek bármelyike kiszolgálhatja a pool- 
hoz érkező kérést. Ez tehát egyfajta ,terheléselosztást" va- 
lósít meg processz szinten - jelentősége főleg többpro- 
cesszoros rendszereknél van: ha az egyik CPU-n zárolunk egy 
worker processzt (egy ASP-lock miatt) , akkor a másik CPU-n 
az ugyanazon alkalmazás poolhoz tartozó másik worker pro- 
cessz még kiszolgálhat kéréseket, nem kell megvárni a záro- 
lás végét. Mindez jelentős teljesítménynövekedéssel jár. 


IIS 6.0 - Metabase és konfigurációkezelés 

Az IIS 6.0 lehetővé teszi kiszolgálófüggetlen metabase 
mentések, webhely- és alkalmazáskonfigurációs mentések 
készítését. A jelszóval titkosított mentéseket egy másik 
webkiszolgálón helyreállíthatjuk, így könnyebben migrál- 
hatjuk és helyezhetjük át az egyes alkalmazásokat, vagy 
webhelyeket más kiszolgálóra. A metabase konfigurációs ál- 
lomány természetesen egy XML fájl (metabase.xml), amit 
akár notepad-del is szerkeszthetünk, a konfigurációk expor- 
tálása pedig szintén XML-be történik. Az új mentési, import 
és export műveletek új Admin Base Object API-n keresztül 
érhetők el, de ADSI-n és WMI-n keresztül szintén hozzáfér- 
hetők. Az IIS WMI provider szintén új az IIS 6.0-ban, segít- 
ségével minden olyan művelet elvégezhető WMI-n keresztül 
is, ami az IIS ADSI provider-en keresztül megtehető. 
Újdonság, hogy a metabase-t az IIS futása közben szer- 
keszthetjük, nem kell a szervízt leállítani. A metabase vál- 
toztatásaira az IIS 6.0 verziókövetést használ, egy meta- 
base history mappát tart fenn, ahol a korábbi metaba- 
se.xml állományok verziószámmal vannak ellátva (á la 
VMS) melynek segítségével könnyen visszaállhatunk egy 
korábbi konfigurációra, ha valamit elrontottunk volna. 


IIS 6.0 - Standard alkalmazásmód 

A dedikált alkalmazásmód jelentősen növeli az alkalmazások 
teljesítményét és stabilitását - kompatibilitási okokból 
azonban az IIS 6.0 tartalmaz egy standard alkalmazásmódot 
is, amely teljesen megegyezik az IIS 5.0 futtatási módjával. 





5 IIS 6.0 standard (kompatibilitási) alkalmazás mód 
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Ha egy IIS 5.0-ra már megírt webalkalmazásunk nem fut 
dedikált mód alatt, akkor is érdemes áttérnünk IIS 6.0-ra, 
mert a standard módú alkalmazásoknál is kihasználhatjuk a 
kernelmódú HTTP.SYS új lehetőségeit a kérések központosí- 
tására és a kernelmódú gyorsítótár kezelésére. 
CGI-alkalmazásokat is érdemes áttenni IIS 6.0 alá: az IIS 
5.0 szinkronban tud csak CGI alkalmazásokat futtatni (a CGI 
folyamatot létrehozó szálat blokkolja az IIS 5.0, amíg a gyer- 
mek CGI folyamat vissza nem tér), míg az IIS 6.0-ban 
aszinkron a CGI végrehajtás, párhuzamosan futnak a folya- 
matok a szülő blokkolása nélkül. 


Scalable Web Cache - SWC 3.0 

Egy jó hír: a kernelmódú web gyorsítótár előnyeit már ma 
kihasználhatjuk, nem kell a Whistler Server-re várnunk! A 
Scalable Web Cache (SWC 3.0) az IIS 5.0-hoz (Windows 
2000 4. SP1) ingyenesen letölthető kernelmódú meghajtó 
[1]. Az SWC 3.0 (hogy egy kollégám kedvenc kifejezésével él- 
Jjek) drámaian megnöveli az IIS 5.0 teljesítményét. A web- 
kiszolgálóknál ipari szabványnak tekintett SPECWeb99 tel- 
jesítményteszten épp a napokban hitelesítették egy 8 utas 
Windows 2000 Datacenter eredményét IIS 5.0-val és SWC 
3.0-val. Ez az eredmény abszolút értékben harmadik, és ez- 
zel az összes Linux-os eredményt maga mögé szorította 
(még a szintén kernelmódú gyorsítótárat használó Red Hat 
TUX webkiszolgálókat is). A dobogós helyezettek most: 


Cég Webkiszolgáló ed au A 
Sun Iplanet WebServer 6.0 12 8739 
IBM Zeus 3.3.7 12 8344 
MSFT  IIS 5.0 4 SWC 3.0 8 8001 


A részletes eredmények a [2] címen tekinthetők meg. A táb- 
lázatból látszik, hogy az első két helyezett 12 processzoros 
konfiguráció - viszont másfélszer annyi processzorral nem 
hoznak másfélszer jobb eredményt, mint a harmadik helye- 
zett 8 utas IIS 5.0. Ezek szerint egy 12 vagy 16 utas Windows 
2000 Datacenter rendszernek elég jó esélyre lehet az első 
helyre (természetesen egy gépen belül ő se fog lineárisan ská- 
lázódni, de a fentieknél valószínűleg jobb eredményt hoz 
majd). És ez még mindig az IIS 5.0, nem pedig a Whistler... 


Active Directory újdonságok 

Azt már a Tech.Net magazin levelezési listáin is megszokhat- 
tuk, hogy az Active Directory gondokra mindig ugyanaz a há- 
rom válasz vonatkozik: DNS, DNS, DNS. A Whistler-ben találunk 
majd egy eszközt, amellyel ellenőrizhetjük és tesztelhetjük, 
hogy DNS-ünk megfelelően van-e konfigurálva az adott AD 
struktúránkhoz, és amely segít felderíteni a hibás beállításokat. 
Telephelyi tartománykiszolgálók telepítésénél jelent segít- 
séget, hogy a kezdeti replikáció nemcsak hálózatról, hanem 
bármilyen médiáról (szalag, CD, merevlemez) is elvégezhe- 
tő - így nem kell a lassú WAN vonalon fél napon át repli- 
kálni, illetve nem kell fizikailag elszállítani a telephelyi gé- 
pet a központba a telepítéshez. 

Az AD talán legnagyobb újdonsága viszont a (tessék meg- 
kapaszkodni!) : 
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Forest trust 

A forest trust-ot két erdő gyökér (root) tartománya között 
kell egyszer definiálni, és ezáltal egy tranzitív megbízotti 
kapcsolat jön létre a két erdő összes tartománya között. A 
forest trust egyirányú, és csak a megbízotti kapcsolat két 
oldalán álló két erdő tartományai szintjén tranzitív, az er- 
dők szintjén nem. Ha tehát A erdő egy forest trust létreho- 
zásával megbízik B erdőben, míg B erdő megbízik C erdő- 
ben, akkor A erdő nem fog megbízni implicite C erdőben, 
csak ha külön A és C között is létrehozunk egy forest trust 
kapcsolatot (azt hihettük, hogy az AD kétirányú tranzitív 
trust kapcsolataival végre nem kell mindig átgondolni, hogy 
mit jelent megbízó és a megbízott félnek lenni — ez a házi 
feladat most visszajön az egyirányú forest trust-nál) . 

Az erdők közötti hálózati és interaktív bejelentkezés NTLM 
és Kerberos felhasználói azonosítással is működik, illetve 
működik a Kerberos megszemélyesítés is, ha egy többréte- 
gű alkalmazás valamelyik rétege egy másik erdőben van. 
Forest trust kapcsolatot nem lehet egymást átfedő névtér- 
rel rendelkező erdők között létrehozni. Az erdők közötti 
névfeloldáshoz a megbízotti kapcsolat kialakításakor létre- 
jön egy ún. Trusted Namespace (Megbízott Névtér) , ami tartal- 
mazza az összes megbízott erdő tartomány-, felhasználó-, 
szolgáltatásneveit és a felhasználói SID-eket. Ha már az er- 
dő Globális Katalógusa sem tud feloldani egy nevet, akkor 
egy új eljárást hív meg a Whistler, ami a fenti Megbízott 
Névtérben próbálja megkeresni az adott nevet. 

A hozzáférésvezérlési listákon (ACL-eken) szintén szerepel- 
hetnek objektumok a megbízott erdőkből is - az objektumok 
teljes nevét meg kell azonban adni, más erdő objektumait 
nem tudjuk kilistázni és nem használhatunk joker karaktere- 
ket sem a név megadáshoz (a Megbízott Névtér ugyanis csak 
névfeloldást végez, katalógusszolgáltatást nem). 

Cégek egyesítésénél, felvásárlásnál nagyon jól jön, de a 
többerdős modell továbbra sem célszerű tervezési szempont. 


LDAP újdonságok 

A Whistler LDAP fejlesztéseket figyelembe véve méginkább 
igaz a fenti állítás. Több erdő kialakításához eddig a leg- 
ütősebb érv a különböző séma iránti szükséglet volt, amit 
egy erdőn belül semmiképp nem lehetett megoldani. A 
Whistler viszont támogatja az AD-ban a Dinamikus Külső 
Osztályokat, ahol a külső osztály által meghatározott új ob- 
jektumtulajdonságok egyedi objektumpéldányokhoz rendel- 
hetők hozzá - azaz meghatározhatjuk azon objektumok hal- 
mazát egy erdőn belül, ahol látni és használni szeretnénk a 
külső osztály tulajdonságait - a többi objektumnál ezek a 
tulajdonságok nem fognak látszani. A Windows 2000-nél 
ezt nem tudtuk megtenni - új tulajdonságot csak a séma 
bővítésével lehetett megadni, ahol a sémában az osztály 
definíciója módosult, és bővült ki új tulajdonságokkal, és 
így egy osztály összes példányára érvényes lett (ezért stati- 
kus ez a módszer). A Dinamikus Külső Osztályok nem nyúl- 
nak a sémához, csak úgy , röptében" rendelődnek hozzá bi- 
zonyos objektumpéldányokhoz. (A következő lépés csoport- 
házirendekkel szabályozni, hogy egy adott szervezeti egysé- 
gen belül milyen objektumokat milyen Dinamikus Külső Osz- 
tályok bővítsenek ki — lehet, hogy ez is benne van a Whist- 
ler-ben, nem tudom, nem néztem...) 
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A Dinamikus Külső Osztályokat (Dynamic Auxillary Classes) 
ne keverjük az ún. Dinamikus Bejegyzésekkel (Dynamic 
Entries) ami szintén új a Whistlerben, de egyébként az IETF 
RFC 2589 megvalósítása: egy dinamikus bejegyzéshez egy 
TTL-t rendelhetünk, aminek lejárta után a bejegyzés auto- 
matikusan törlődik a címtárból. (Ha rosszmájú akarok len- 
ni, akkor egy User objektum is lehet dinamikus, a TTL-jét a 
munkaszerződésének időtartamára állíthatjuk...) 

Az LDAP kapcsolatok TLS (Transport Layer Security) haszná- 
latával titkosíthatók (RFC 2830). 

Virtual List View (VLV): ezt néhányan félreértelmezték már, 
pedig ez is egy IETF által definált LDAP kiterjesztés - ha 
egy LDAP ügyfél nem akarja lehozni a kiszolgálóról egy 
LDAP lekérdezés teljes eredményét, mert az túl sok adat 
lenne, akkor a VLV segítségével ,ablakozhat" az eredmény- 
ben, kisebb részeket hozva csak át a hálózaton. 

Talán mindannyian hallottuk már azokat a vádakat, miszerint 
az Active Directory LDAP megvalósítása nem szabványos. Ez 
főleg a Novell és a Netscape vesszőparipája volt, mondván, 
hogy az AD nem az inetOrgPerson osztályból származtatja a 
User objektumot, amint az az RFC 2798-ban írva vagyon. 

Az igazságot mindannyian tudjuk: az RFC 2798 még csak 
draft állapotban volt a Windows 2000 elkészültekor, és 
egyébként sem tette kötelezővé az inetOrgPerson-ból való 
származtatást. A Windows 2000 ezért a már régen elfoga- 
dott és érvényben levő RFC 2254 szerint az Organizational- 
Person osztályból származtatta a felhasználókat. Ennyit ar- 
ról, hogy ki a szabványos. A Whistler az alap AD sémában 
támogatja az inetOrgPerson-ból származtatott felhasználó- 
kat is, minden megszokott művelet elvégezhető rajtuk, gra- 
fikus felületről is, LDAP-on és ADSI-n keresztül is. (Ez a ,, Na 
Jó, legyen igazatok, csak hagyjatok már békén..." tipikus esete...) 


Csoportházirendek 

160 új csoportházirendet tartalmaz a Whistler Beta 2 a 
Windows 2000-hez képest. Ez csak a legkisebb újdonság a 
csoportházirendek terén: talán a leginkább használható 
fejlesztés az ún RSoP (Resultant Set of Policies, azaz Eredő 
Csoportházirend) . Ez egy eszköz, mely a FullArmor cég ál- 
tal gyártott FAZAM2000 termékhez hasonlít, melynek kor- 
látozott változatával a Windows 2000 SP1-en, funkciókész- 
letével pedig e szám GPO cikkében találkozhatunk (tesse- 
nek odalapozni!). Segítségével grafikus felületen elemez- 
hetjük, hogy egy adott felhasználóra és egy adott gépre 
különböző szinteken előírt házirendek, öröklődéssel, blok- 
kolással és minden egyéb furmánnyal megtűzdelve végül is 
milyen eredő beállítást fognak eredményezni. Az eszköz a 
csoportházirend beállítások megtervezésében is segít, 
hogy végül minden szinten, minden objektumra azt a ha- 
tást érjük el, amit szeretnénk. 

Az egyes új beállítások közül érdekes a Netlogon szolgál- 
tatás összes beállításának szabályozása a tartományvezér- 
lőkön csoportházirenddel: dinamikus DNS regisztráció, te- 
lephelyfelderítés, stb., de ugyanígy szabályozható a termi- 
nálszolgáltatás minden aspektusa is. Na és most tessék fi- 
gyelni: WMI szűrés csoportházirend objektumokon! Bi- 
zony! Hasonlóan, ahogy egy GPO-t biztonsági csoportokra 
tudunk szűrni a Jogosultságok fülön, egy új fül is meg fog 
jelenni, ahol WMI lekérdezések eredményeire szűrhetünk. 
Meg tudjuk pl. adni, hogy egy házirend csak arra a gépre 
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legyen érvényes, amiben 100 Mb-es hálókártya van, vagy 
csak arra amiben hálókártya van... (emlékeznek, mit írtam 
az áprilisi szám bevezetőjében a felügyeleti technológiák, az 
SMS és az Active Directory közeledéséről?) 


Terminálszolgáltatás 

A legnagyobb újdonság itt az, hogy a munkaállomás, a Win- 
dows XP Professional is tartalmazza a beépített terminál- 
szolgáltatást - ezért erről a Windows XP cikkben írunk majd... 
Mindenesetre említsük meg az átirányítási lehetőségeket 
(hang, fájlrendszer, port, nyomtató, vágólap átirányítás, 
azaz az ügyféloldal ezen erőforrásai a terminál ügyfél mun- 
kamenetben (session) is látszanak és használhatók). Új- 
donság a Terminal Services Virtual Channel API, amivel az 
átirányítási funkciót egyéb erőforrásokra is kibővíthetjük 
saját alkalmazásunkból. 

A hang átirányításnál a hangfolyam automatikusan a ren- 
delkezésre álló sávszélességre lesz optimalizálva, nem 
kell külön állítgatnunk. 


Smart card támogatás 

A smart card azonosítás köre kibővül, pl. terminál kiszolgá- 
lóra is be tud jelentkeztetni a terminálügyfél jelszó és fel- 
használónév nélkül, csak a smart card használatával. 

A bejelentkezésen kívül számos adminisztrációs eszköz is 
tudja majd a Rendszergazdát smart card-ról azonosítani, név 
szerint a grafikus DCPromo, ,Run As" és ,Map Network Dri- 
ve", illetve a parancssori ,run as" és a net.exe. (Hogy mik 
ezek? Lapozzon a ,, Szerszámosláda" rovathoz! — a szerk.) 


Egyebek 

A tervek szerint mind a Whistler Server, mind a Windows XP 
Personal és Professional tartalmaz majd egy beépített tűzfa- 
lat (Personal Firewall), a LAN, VPN és betárcsázásos (DUN) 
kapcsolatok védelmére - és alapszintű behatolásvédelmet is 
tudni fog (a portszkennelés elleni védelmet legalábbis) . Igaz, 
hogy az ISA Server 2000 a hitelesített, ICSA minősítéssel 
rendelkező tűzfal, de a tech.net levelezőlistákon is gyakran 
felbukkan a kérés, hogy egy jó, olcsó (lehetőleg ingyenes) 
tűzfalat keresnének... Ez most az operációs rendszer része 
lesz. Hot-plug memória: ha a hardver is támogatja, a Whist- 
ler Server-ben működés közben bővíthetjük a memóriát, ami 
azt be is konfigurálja, az alkalmazások és az operációs rend- 
szer újraindítás nélkül azonnal használhatják. 


Horváth Tamás 
Microsoft Magyarország 
tamash amicrosoft.com 







soft.com/i iS/Swc3.asp 
spec.org/osg/web99/results/res2001g2 
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Programtelepítés Group Policyval 

Az előző részben eljutottunk a programtelepítés küszöbéig, 
ebben a hónapban ott folytatjuk, ahol májusban félbe hagytuk: 
ha nincs új típusú MSI fájl a telepítendő alkalmazáshoz, ak- 
kor a Veritas cég Winlnstall szoftverével készíthetünk egyet. . . 


Winlnstall LE használata 

A program egyszerűsített változata (Light Edition) meg- 
található a Windows 2000 Server CD VALUEADDNSRDPARTYV 
MGMTWINSTLE mappájában. Az alkalmazást új csomagok 
létrehozása mellett már meglévők módosítására is használ- 
hatjuk. A WinInstall LE működési alapelve a telepített al- 
kalmazás által végzett módosítások (fájl, registry stb.) 
összegyűjtése. Ehhez ,lefotózzuk" az operációs rendszer 
állapotát a telepítés előtt, majd elvégezve a telepítést a 
fotó" alapján megállapíthatók a változások. 

Új telepítési csomag elkészítéséhez két számítógépre van 
szükségünk. Az egyikre próbaként telepítsük fel azt az alkal- 
mazást, amelyiket szeretnénk elterjeszteni a vállalatunknál. 
Fontos, hogy előzetesen erre a gépre az operációs rendsze- 
ren és a megfelelő szervizcsomagon kívül mást ne tegyünk 
fel. Így biztosítható ugyanis, hogy a próbatelepítés során a 
fájlrendszeren és a regisztrációs adatbázisban bekövetkező 
összes változást (és csak azt!) regisztrálni tudjuk. A másik 
számítógépre pedig a Winlnstall LE-t telepítsük. 

Mielőtt a referenciául szolgáló számítógépen elvégeznénk 
a próbatelepítést, le kell futtatnunk a Winlnstall Discover 
(DISCOZ.EXE) elnevezésű segédprogramját (before snap- 
shot) az alapállapot ,lefotózásához". 

A Discover elindítását követően először meg kell adnunk az 
elterjesztésre váró alkalmazás nevét, illetve az elkészítésre 
elérési utat, akkor a csomag a Winlnstall Iköryytátában Jön lét- 
re.) Ezt követően a Discover munkakönyvtárának meghajtóját 
kell kijelölnünk. A program - átmenetileg - itt hozza létre a 
DISCOVER.WRK nevű könyvtárat, amelybe a működéshez szük- 
séges fájlok kerülnek. A teljesítmény növelése miatt lokális 
meghajtót válasszunk. Gondolnunk kell arra is, hogy a kisze- 
melt partíción legalább 250 MB szabad hely legyen. 

A Next gomb megnyomása után feltűnő párbeszédablakon azt 
a meghajtót, illetve azokat a meghajtókat kell kijelölnünk, 
ahol a próbatelepítés során változások következhetnek be. 
Végezetül lehetőségünk van olyan mappákat kivonni az el- 
lenőrzés alól, amelyeknél biztosan nem várható módosulás. 
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o A hatékonyság növelése végett fájlokat és könyvtára- 
kat vonhatunk ki az ellenőrzés alól 


Miután a Discover feltérképezte az aktuális konfigurációt, 
következhet az elterjesztésre váró alkalmazás telepítése. A 
folyamat befejezéseként ismét le kell futtatnunk a Disco- 
ver segédprogramot (after snapshot). Ennek során a prog- 
ram rögzíti mindazokat a változásokat, amelyek a próba- 
telepítés során létrejöttek. A csomag és az alkalmazás el- 
terjesztéséhez szükséges állományok abban a könyvtárban 
lelhetők fel, amelyet a Discover elindítása után adtunk 
meg az .msi fájl tárolóhelyeként. 


Csomagok módosítása Winlnstall Console-lal 

Sok esetben előfordul, hogy a telepített programon utólag 
több beállítást is módosítani kell, hogy illeszkedjen a válla- 
latnál elterjedt konfigurációhoz. Abban az esetben, ha a te- 
lepítés számos munkaállomást érint, fontos szempont, hogy 
ezeket a változtatásokat automatizálni tudjuk. Szerencsére a 
Windows Installer csomagokban tárolt információkat köny- 
nyen módosíthatjuk a VERITAS Software Console jóvoltából. 
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5 A Windows Installer csomag tartalma a VERITAS Con- 
sole-on keresztül szemlélve 


tech.net! 


WINDOows 2000 


Ezzel a módszerrel nagyon hatékonyan tudjuk a program- 

telepítést testre szabni: 

"8 megváltoztathatjuk az összetevőket 

"8 lehetőségünk van, hogy a programmal együtt új be- 
tűtípust is telepítsünk 

"0 módosíthatjuk a telepítendő szervizek beállításait 

0 speciális jogosultságot rendelhetünk fájlokhoz 

"8 megszabhatjuk, hogy a programhoz tartozó parancs- 
ikonok megjelenjenek-e a Start menüben, illetve a 
Munkaasztalon 

"0 módunkban áll kulcsok és bejegyzések létrehozására és 
törlésére a regisztrációs adatbázisban 

Bár az iménti felsorolás nem teljes, talán jól érzékelteti a 

csomagok módosításában rejlő lehetőségeket. 

A VERITAS Winlnstall LE teljes ismertetése túlnő ezen cikk 

keretein. A program működésével kapcsolatos leírás meg- 

található a Microsoft honlapján [1]. 


A csoportos házirend programtelepítési modulja 
A Group Policy snap-in Computer ConfigurationtY Software 
Settings, valamint a User Configuration Software Settings 
mappájában található a programok telepítésére szolgáló 
modul. E két modul esetében különböző telepítési eljárá- 
sokat engedélyezhetünk: 
8 Publish to Users: Lehetőségünk van a telepítést a felhasz- 
nálók számára közzétenni. Ebben az esetben a felhaszná- 
lónak kell gondoskodnia a telepítés elindításáról a Cont- 
rol Panel —a Add/Remove Programs —2 Add New Prog- 
ram segítségével. Ha olyan házirendobjektumnál engedé- 
lyezzük a szoftvertelepítést, amely már érvényben van a 
felhasználóknál, akkor nem kell újra bejelentkezni a tele- 
pítés indításához. Fontos tudni, hogy a felhasználók bár- 
mikor újratelepíthetik az alkalmazást mindaddig, míg 
ezt le nem tiltjuk a Group Policy snapinben. Sőt, lehe- 
tőségük van a program eltávolítására is! 

Assign to Users: Az előző módszerhez képest további 

szolgáltatás is rendelkezésünkre áll: a telepítés a 

program első használatakor is elindítható. A telepí- 

tendő program ikonja ugyanis a felhasználó bejelent- 
kezését követően megjelenik a Start menüben. 

0 Assign to Computers: A telepítés a számítógép újraindí- 
tásához kötött, és a felhasználó beavatkozása nélkül 
megy végbe. Ilyenkor csak a lokális rendszergazdai jo- 
gosultsággal rendelkezők tudják a programot eltávolítani. 

Első lépésként tehát azt kell eldöntenünk, hogy a három 
lehetőség közül melyik felel meg legjobban a céljainknak. 
Ezután hirdethetjük meg telepítésre a Windows Installer 
csomagot: jelöljük ki a megfelelő szoftvertelepítési mo- 
dult, majd kattintsunk az Action menüben a New/Package 
parancsra. Az Open párbeszédablakban keressük meg azt a 
megosztott mappát, ahova a telepítendő állományokat má- 
soltuk. Lényeges, hogy az elérési utat mindig az univerzá- 
lis névkonvenciónak (UNC) megfelelően adjuk meg. Érte- 
lemszerűen ezáltal válik egyértelművé, hogy melyik szer- 
ver melyik megosztásáról történjen a telepítés. 


8] 
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9 A rendszergazdai eszközök telepítésének meghirdetése 


Ha mindig ugyanazt a szervert és megosztást használjuk 
az automatikus telepítésre, akkor érdemes az elérési utat 
a modul tulajdonságait leíró párbeszédablakon (Action me- 
nü Properties utasítás) megadni. 


EJB 
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Defaut package locator 

Browse... 

1 New packages: 
] When adáng new packages to user setlings: 
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[7 installation user interface options 
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TT Uninstall the appbcations when theg fall out of the scope of 
menagement. 





5 A szoftvertelepítés alapértelmezett beállításai 


Emellett más hasznos beállítási lehetőségünk is adódik. A 
New packages szekcióban meghatározhatjuk, hogy melyik 
legyen az alapértelmezett telepítési mód. Ha meghagyjuk 
a Display the Deploy Software dialog box beállítást, akkor 
minden új csomag létrehozásakor egy párbeszédablakon 
kell meghatároznunk a kívánt telepítési fajtát. 

Az Installation user interface options-nál szabályozhatjuk, 
hogy a telepítés során mennyi tájékoztató üzenet, illetve 
beavatkozási lehetőséget biztosító párbeszédablak jelen- 
jen meg a felhasználóknak. Alapértelmezésben (Basic) csak 
a progress bar lesz látható. Ha azt szeretnénk, hogy min- 
den telepítési üzenet, párbeszédablak stb. megjelenjen, 
akkor válasszuk a Maximum rádiógombot. 

Gyakori eset, hogy a szoftvertelepítés csak egy meghatáro- 
zott szervezeti egységhez tartozó felhasználókat érint. Így, 
ha valamelyik dolgozó átkerül egy másik szervezeti egység- 
be, akkor a programhasználatra már nem jogosult. A gyakor- 
latban ez azt jelenti, hogy a szóban forgó munkatárs számító- 
gépéről a szoftvert el kell távolítani. Erre a problémára kínál 
nagyon elegáns megoldást a Software Installation Properties 
párbeszédablak alján található beállítás. Az , Uninstall the 
applications when they fall out of the scope of manage- 
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ment" jelölőnégyzet engedélyezésekor - ha a csoportos házi- 
rendobjektum már nem érvényes a felhasználóra - az operá- 
ciós rendszer eltávolítja a programot. 

A szoftver automatikus eltávolításának nem ez az egyedüli 
módja. A Group Policy snap-inben meghirdetett csomagok 
törlésénél (Action menü —e All Tasks —e Remove) két vá- 
lasztási lehetőségünk van. Egyrészt megszüntethetjük a 
csomag meghirdetését, vagyis megakadályozzuk a további 
telepítést (,Allow users to continue to use the software, 
but prevent new installation" rádiógomb). Másrészt a cso- 
mag eltávolítása mellett utasítást is adhatunk a már tele- 
pített program eltávolítására (, Inmediately uninstall the 
software from users and computers" rádiógomb). 


A hibakeresés lehetőségei 

Az automatikus programtelepítés során előforduló főbb esemé- 
nyekről bejegyzés készül az Application Event Logba. A telepí- 
tésre vonatkozó információk esetén az , Application Manage- 
ment" felirat jelenik meg az Eseménynapló Source oszlopában. 
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0 A Group Policy Software Installation bejegyzései az 
Application Event Logban 


lesse 





Módunkban áll az imént említettnél részletesebb naplózást 
beállítani (Verbose Logging). A regisztrációs adatbázisban a 


HKEY LOCAL MACHINEYSOFTWAREMWMicrosoftNl 


4 Windows NT(CurrentVersionlWDiagnostics 


kulcs alatt kell létrehoznunk az "Appmgmtdebuglevel" - 9b 
(DWORD) bejegyzést. A részletes diagnosztikai és tájékoz- 
tató bejegyzések (például: melyik házirendobjektum érvé- 
nyesül a felhasználók és számítógépek esetén, a telepítéssel 
kapcsolatos esetleges hibakód stb.) a "9owindirYotdebugY 
usermodelappmgmt.1log-ban találhatók meg. 

Még bővebb információhoz juthatunk a regisztrációs adat- 
bázis másik bejegyzése révén: 


HKEY LOCAL MACHINEYSOFTWARElPolicieslMicrosoftN 


8 WindowsVInstallerlLogging-—" voicewarmup" 
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Ezt a beállítást a Group Policy révén is érvényre juttathatjuk 

(Computer Configuration Windows Components ILogging) . 

A bejegyzés értékének mindegyik karaktere különböző nap- 

lózási módot állít be: 

"A v: részletes naplózás 

o: a ,emezterület megtelt" üzenet rögzítése 

i: állapotüzenetek 

c: a felhasználói felületen megadott paraméterek 

e: az összes hibaüzenet naplózása 

w: figyelmeztetés a nem végzetes hibákról 

a: a telepítés fő lépéseinek naplózása (például: pa- 

rancsikonok elkészítése, komponensek telepítése) 

r: a telepítés fő lépéseinek részletezése (például a te- 

lepített komponensek felsorolása) 

"B m: kevés memória miatti leállás naplózása 

"8 u: User reguests 

"8 p: Terminal properties 

A karaktereket tetszőleges sorrendben adhatjuk meg. Érdemes 

gondosan megválasztani a naplózás részletességét, mert a túl 

sok adat rögzítése értelemszerűen lassítja a programtelepítést. 

A Windows Installer működésével kapcsolatos bejegyzések két 

külön állományba kerülnek. A felhasználó által kezdeménye- 

zett események (például a telepítés indítása az Add/Remove 

Programs alól) a "yotemp9oMMSI".log, míg a központi telepítés- 

sel összefüggő információk (például szoftvercsomag meghirde- 

tése) a "owindirJot"temp WSI".log fájlban találhatók. 

A Windows 2000 Server Resource Kit is kínál eszközt a hi- 

bakeresésre. Az addiag.exe elnevezésű segédprogram az ál- 

talános diagnosztikai adatok mellett a következő informá- 

ciókat gyűjti össze számunkra: 

"8 a bejelentkezett felhasználó adatai (felhasználói név, SID, 
a profil típusa, a bejelentkeztetést végző szerver neve stb.) 

"0 a telepített, illetve telepítésre meghirdetett programok- 
kal kapcsolatos, a regisztrációs adatbázisból származó 
információk 

"8 az Active Directoryban fellelhető, a meghirdetett szoft- 
verre vonatkozó információk 

"8 az Eseménynapló megfelelő bejegyzései 

Az imént felsorolt módszerek kifejezetten a programtelepí- 

tés hibáinak feltárására szolgálnak. A csoportos házirend 

végrehajtásával összefüggő problémák felderítésére más 

eszközök is rendelkezésünkre állnak. 


d HFÁddddo 


A csoportos házirend végrehajtásával kapcsolatos hibák 
feltárása 

A problémák okának megállapításához sok esetben elegendő az 
Eseménynapló részletes naplózási funkciójának engedélyezése: 


HKEY LOCAL MACHINElSoftwarelMicrosoftlWWindows NTY 
GW cCurrentVersionwiagnosticsN 


3, RunDiagnosticLoggingGroupPolicyzl (DWORD). 


Az operációs rendszer nem rögzíti az összes figyelmeztetést 
és hibaüzenetet az Event Logba. Sokkal több információhoz 
jutunk, ha az úgynevezett Userenv naplózást alkalmazzuk: 


HKEY LOCAL MACHINElSoftwarelMicrosoftlWindows NTY 


4 CurrentVersionlWinlogont 


4 UserenvDebugLevel-0x10002 (DWORD). 
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A csoportos házirend végrehajtásával összefüggő adatok a 

9owindiryotdebug usermode Userenv.log elnevezésű fájlban 

lelhetők fel. Ha az állomány mérete meghaladja az 1 MB- 
os méretet, akkor a rendszer újraindításakor az adatokat 
az operációs rendszer átmásolja a userenv.bak-ba, és egy 

új Userenv.log fájlt hoz létre. Ügyeljünk arra, hogy ha a 

csoportos házirendben gyakori frissítést állítottunk be, 

akkor a fájl mérete intenzíven növekszik. A usermode 
mappán érvényes biztonsági beállítások miatt a naplófájl 
elolvasásához rendszergazdai jogosultság szükséges. 

A házirendobjektum szerkesztésekor előforduló hibák rögzí- 

téséhez a regisztrációs adatbázis Winlogon kulcsa alatt a 

GPEditDebugLevel-0x10002 (DWORD) bejegyzést kell létre- 

hoznunk. A hibaüzenetek lelőhelye a 9owindirYotdebugY 

usermodetgpedit.log lesz. 

A Windows 2000 Resource Kit is több hasznos alkalmazást 

kínál: 

"0 Group Policy Verification Tool: A gpotool.exe többek 
között alkalmas a házirendobjektumok állapotának 
meghatározására, illetve replikációjuk ellenőrzésére. 

0 Active Directory Replication Monitor: A tartományvezér- 
lőkön elhelyezkedő házirendobjektumok esetében az 
Active Directory nem megfelelő replikációja is számos 
hiba forrása lehet. Az AD replikációs hibáinak nyomon 
követésére nagyon jól használható a replmon.exe. 

0 Group Policy Results Tool: A gpresult.exe részletes in- 
formációt szolgáltat a végrehajtott csoportos házirend- 
objektumokról, tájékoztat a végrehajtásban résztvevő 
tartományvezérlő nevéről, valamint a regisztrációs adat- 
bázisban végbement változásokról. 

"0 Network Connectivity Tester: Speciális esetben előfor- 
dulhat, hogy a házirend végrehajtásának útjában há- 
lózati problémák állnak. Ennek megállapítására jól al- 
kalmazható a netdiag.exe. 


FAZAM 2000 

A csoportos házirend szolgáltatásainak széles körével nagy- 

ban megkönnyíti a rendszergazdai feladatokat. Hatékony ke- 

zeléséhez viszont alapos ismeret szükséges, amelynek meg- 

szerzése időigényes folyamat. A FulláArmor Corporation [2] 

FAZAM 2000 (FullArmor Zero Management for Windows 2000) 

néven olyan eszközt fejlesztett ki, amellyel csökkenthető a 

csoportos házirend adminisztrációjára fordított idő. A FAZAM 

2000 segítségével ugyanis olyan feladatokat is elláthatunk, 

amelyeket a Group Policy beépített eszközeivel nem. Például: 

"0 a házirendstruktúra grafikus megjelenítése, amely nagy 
segítséget nyújt a tervezésben és a hibaelhárításban 

"8 házirendobjektumok archiválása és visszaállítása a 
szervezeti egységekhez fűződő kapcsolatuk figyelem- 
bevételével 

"B egyes rendszergazdai feladatok automatizálása scrip- 
tek segítségével 

-8 házirendobjektumok replikálása tartományok és er- 
dők között 

"8 hibakeresés lehetősége távoli munkaállomásokon 

Az imént felsoroltakon kívül a FAZAM 2000 képes elemez- 

ni például egy új házirendobjektum bevezetésének várha- 

tó eredményét: 
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"8 az új GPO érvényesülésekor pontosan milyen beállítá- 
sok lesznek érvényesek valamely felhasználóra 

- az új beállítások nem kerülnek-e konfliktusba a korábbiakkal 

Az elemzés során három tényezőt tudunk megvizsgálni: 

"0 a felhasználó tagja valamelyik csoportnak 

"8 a felhasználó nem tagja egy bizonyos csoportnak 

8 a felhasználó átkerül egy másik szervezeti egységbe 

A tényezők hatásának vizsgálatakor felhasználói azonosítón 

kívül mindig meg kell határozni a munkaállomás nevét is. 





Perform Analysis 2 
User Burgundi Margit Browse... 
Machine: PROF Browse... 





50 Mi történik, ha Burgundi Margit a Domain Admins 
csoport tagjává válik? 


Erre azért van szükség, mert a FAZAM 2000 a lokális házi- 
rendbeállításokat is figyelembe veszi. Az elemzés az örök- 
lődési szabályok figyelembevételével készül, így teljes ké- 
pet kapunk a beállítások várható hatásáról. 











TX FAZAM 2000 EVALUATION Version 8 f zIOI2] 
y Console Window Help csö sé 1.-1elad] 
tni - z] 
(CI FAZAM 2000 Console fetaw Registry Data ! 
B 181 FAZAM 2000 administrator ÍUser Policy 
8 Hpahu SoftwarelMicrosoftWindowaAlCurrentVersionlPolicieslExplorer 


BY FAZAM 2000 Pokcy Planning 





Hypo.hu NosSavesSettings I 
5 ÍJ Burgundi Margit at V NoDeletePrinter l 
A I User Heerarchy ForceStartMenuLogOfT 
p-lág GTST SoftwarelMicrosoftWindowsAXCurrentVersioniP oliciesiSystem 
jdr ÉLEEE DisableRegistryTools 
7 Ef) Machine Hierarci RunLogonScniptSync I 





(a cprsr 
(2) Hypo 














a lés see SoftwareXPoliciestMicrosofWindowsiSystem I 
HEZ sztee DisableCMD 
eza tudta [ [Machine Policy 


AB Remote Diagnostics 
ÉJ offune Diagnostics 
EB cent Side Auditing 


al ] s] 


5 Az elemzés végeredményének egy részlete 





DCOption 


EFSBlob 





Account Policies 
Password Policy 


al 


SoftwarelPolicieslMicrosoftWindowsiGroup Policy Editor 


SoftwarelPoliciesümierosoftSystemCertifcateslEFS 





A FAZAM 2000 nagyon hasznos szolgáltatása, hogy a hi- 
bakeresés céljából távoli munkaállomásokon is le tudjuk 
futtatni az elemzést. Ezt a funkciót csak azután vehetjük 
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WINDOows 2000 A CSOPORTOS HÁZIREND 
igénybe, hogy a munkaállomásokon telepítettük a FAZAM 
2000 kliensoldali komponensét. A vizsgálatra kiszemelt szá- 
mítógéphez a FAZAM 2000 Policy Auditing 8. Diagnostics alatt 
található Remote Diagnostics modul révén kapcsolódhatunk 
hozzá (Action menü Select Machine parancs) . Az elemzés nem- 
csak a számítógép, de a szóban forgó munkaállomásról beje- 
lentkezett összes felhasználói azonosító beállításait érinti. 
Így vizsgálatunk tárgyát képezheti például valamelyik futó 
szervizhez rendelt felhasználói azonosító házirendje is. 














Í aeion ven [6 9 





Tree] 





(Ö FAZAM 2000 Console 

3-4 FAZAM 2000 Administrator (bos-fa-ad-OL .FULLARMOR. COM] 
4) FAZAM 2000 Pokcy Planning 8 Analysis 

AM FAZAM 2000 Policy Auditing $ Diagnostics [azra.Hypo.huj 





Machine Settings 
AA Administrative Template 
G Securty 
a A EFS recovery 
AA Application Management 
User Settings 
HYPOLadmin " 
AA Administrative Template 
Scripts 
Internet Explorer Branding 
E £2 HiPOtburgundim " 
a Administrative Template 

Internet Explorer Branáng 

EZ offune Diagnostics 
B-ÉM Cent Side Auditing 


























0 A Group Policy beállítások távoli elemzése a 
W2KPROF nevű munkaállomáson 


0 A számítógépen dolgozó munkatárs házirendje 


0 A munkaállomáson futó szervizhez rendelt felhasználói 
azonosító házirendje 


A cikkben szereplő URL-ek: 


(II. RÉSZI 


Arra is van lehetőségünk, hogy az elemzést helyben, a prob- 
lémás számítógépen végezzük el, és az adatokat később ér- 
tékeljük ki az Offline Diagnostics szolgáltatás segítségével. 
Az adatgyűjtést a FAZAM 2000 fadiag.exe nevű segédprog- 
ramja végzi, amelyet azon a számítógépen kell lefuttatnunk, 
amelyiken a hibát tapasztaltuk. A programot parancssorból 
érdemes indítani, mert paraméterként meg kell adnunk egy 
fájlnevet, amelybe az összegyűjtött információk kerülnek. A 
FullaArmor ajánlása alapján a fájlnak .dgn kiterjesztést ad- 
junk, hogy jól megkülönböztethető legyen egyéb diagnosz- 
tikai információkat tartalmazó állományoktól. Az adatok ér- 
tékeléséhez az Offline Diagnostics módulnál kell megadnunk 
lényeges különbség a Remote Diagnosticshoz képest, hogy az 
Offline Diagnostics által szolgáltatott adatok csak a számító- 
gép, illetve a munkaállomáson éppen dolgozó munkatárs házi- 
rendjére vonatkoznak. Ezzel a módszerrel tehát nem tudjuk ele- 
mezni a szervizhez rendelt felhasználói azonosító beállításait. 
Mint látható, a FAZAM 2000 a Group Policynál bővebb 
szolgáltatási körrel rendelkezik. Ennek tükrében különösen 
fontos hangsúlyozni, hogy a FullArmor célja nem a csopor- 
tos házirend kiváltása, hanem egy olyan könnyen kezelhe- 
tő eszköz megalkotása volt, amely a tervezéstől a hibael- 
hárításig hatékonyan segíti a rendszergazdák munkáját. 

A FAZAM 2000 egyszerűsített változata utólag bekerült a 
Windows 2000 Resource Kit alkalmazásai közé. A telepítő- 
készlet letölthető a Microsoft honlapjáról [3]. 


Tomasz Balázs 
balazs.tomaszohu.hypovereinsbank.com 
pszichológus 


[1] http://www. microsoft.com/windows2000/library/ / planningymanagement/veritas.asp 


[21 http://www.fullarmor.com 


[3] http://www.. microsoft.com/windows2000/techinfo/reskit/ Fgolszeistindtazam zó dd So: asp 
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Runas és 
Whoami 


Ha valaki nem olvasta volna az előző részt (egy hónap kiha- 
cikksorozatunkban a Windows 2000-hez kapcsolódó hasz- 
nos Microsoft segédprogramokat részletezem. Az alábbi for- 
rásokból emelek ki alkalmanként néhány fontosabb eszközt: 
9 Windows 2000 Server 

2 Windows 2000 Support Tools 

2 Windows 2000 Server Resource Kit 

Az adott források elérhetőségét az első részben részletez- 
tem, ebből is látszik hogy érdemes visszamenőleg beszerez- 
ni a magazinszámokat :). 


Másodlagos bejelentkezés 

Elérhetőség: X:(WINNTNYSTEM32 vunas.exe 

Forrás: Windows 2000 Server (és Professional) 

Ez a kombináltan parancssoros és grafikus, beépített Win- 
dows 2000 parancs lehetővé teszi például egy rendszergaz- 
da számára, hogy a felhasználó aktuális bejelentkezéséhez 
tartozó jogosultságoktól eltérő jogosultságokkal futtasson 
egy eszközt vagy programot anélkül, hogy a júzernek ki kel- 
lene jelentkeznie. Ezt a UNIXban az su parancs és testvérei 
oldják meg. Egy biztonsági jótanács, amelyben a runas s0- 
kat segít: mivel sokan a rendszergazdai munkaállomáson 
egyéb tevékenységet is végzünk (pl. levelezés, web), aján- 
lott mindezt egy , halandó" felhasználói kontextusban ten- 
ni, a különféle biztonsági kockázatok miatt (trójai és féreg- 
vírusok, stb). Természetesen fordítva is alkalmazható - 
mint bármilyen fegyver - a rendszergazda egyszerűen tud- 
ja a korlátozott környezeteket finomhangolni a felhaszná- 
lók számára, mivel szintén futtathatja az adott alkalmazá- 
sokat az ő nevükben. Ezekben a helyzetekben használható 
a runas parancs, mivel a szélesebb jogosultságot igénylő 
feladatokat is végezhetjük a megszokott felhasználói kör- 
nyezetünkből, felesleges ki-bejelentkezések nélkül. 

A parancssorból (és a parancsikonokból) futtatható runas az 
alábbi szintaktikával működik: 


runas [/profile)] [/env] [/netonly] 


/user:Felhasználói fiók neve "program" 
Egy egyszerű példa: 
runas /user:DOMAINMAdministrator "cmd" 


Ez a példa a rendszergazda nevében indít egy konzolt. A fel- 
használónevet két formátumban is megadhatjuk: a hagyomá- 
nyos tartomány felhasználónév, és a felhasználónévDtarto- 
mány (UPN) formában. Az [1]-es címen található KB cikk 
leírja azt a bizonyos hibajelenséget, amely a username(2do- 
main.stb (UPN) formátumú felhasználónévmegadás esetén 
jöhet elő a runas használatakor SP1-es környezetekben. 
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A kapcsolók közül a /profile jelzi, hogy ne az eredeti fel- 
használó profilját értelmezze a rendszer - tehát ez dönti el, 
hogy az alapértelmezett temp, My Documents mappák közül 
melyik felhasználóét veszi figyelembe. A /env a környezeti 
változókkal machinál (SET TEMP, SET WINDIR stb.). Megad- 
hatjuk, hogy az aktuális változókat használja a parancs a 
felhasználó helyi környezete helyett. Szintúgy a /netonly 
kapcsoló, amellyel beállíthatjuk, hogy csak távoli kapcsola- 
tokra legyen érvényes a runas - így kisebb az esélye, hogy 
a lokális felhasználó gépén véletlenül kárt teszünk. A jelsza- 
vakat meglehetősen biztonságosan kezeli ez a parancs: eltá- 
rolni nem hagyja őket - a parancssoros alkalmazásnál a vég- 
rehajtás közben kérdezi meg azt. Ha munkaállomásról sze- 
retnénk a teljes Windows 2000 tartományt kezelni, további 
lépésekkel fel lehet telepíteni a teljes Windows 2000 admi- 
nisztrátori eszközkészletet. Ezek egy része már megtalálha- 
tó a Windows 2000 Professional-ben, az Administrative 
Tools (Rendszerfelügyeleti eszközök) között, de pl. az Active 
Directory Users and Computers, és más hasonló tartományi 
eszközök csak az adminpak.msi telepítése után érhetőek el. 
Ezt a javítócsomagok (SP1 és SP2) megfelelő állományából 
telepíthetjük a jobbklatty után az install menüpont kiválasz- 
tásával. Ha a gyárilag a Professional változatban szereplő 
eszközöket (pl. Computer Management) a Control Panel/Ad- 
ministrative Tools felől közelítjük meg, a megnyíló ablakban 
az adott eszköz ikonján a jobbklikk után megjelenő kis me- 
nüben megtalálható a , Runas" lehetőség is. Más parancsiko- 
noknál további lépésekre van szükség, hogy a jobbkattintás- 
sal ezt a funkciót is elérhessük, így az adminpak.msi telepí- 
téséből származóaknál is. Tehát: ha a jobb-kattintás közben 
a SHIFT billentyűt nyomvatartjuk, akkor bármely parancsiko- 
non elérhető lesz a Runas opció is (ilyenkor a /profile kap- 
csolót használja a rendszer). Ilyenkor egy ablak ugrik elénk, 
ahol a megcélzott felhasználó paramétereit (név, jelszó, tar- 
tomány vagy gép) kell megadnunk. 
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a Halandóból Administrator -— csak egy jobbklikk 
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A runas parancssori paraméterezése egyértelműen felhasznál- 
ható parancsikonok létrehozásánál. Ilyenkor egy adott prog- 
ram (MMC, stb) helyett a már felparaméterezett runas-t tárol- 
juk le a hivatkozásban. Alapfeltétel ezen parancs használatá- 
hoz, hogy a Runas szolgáltatás fusson - amelyet célszerű az 
alapbeállításon, azaz az automatikus induláson hagyni. 


DNS kiszolgáló vezérlése konzolról 

Elérhetőség: X:(Program Files) Support ToolsYdnscmd.exe 
Forrás: Windows 2000 Support Tools 

A DNS kiszolgálók és adatbázisaik hagyományos tartozéka 
(pl.: BIND) a text zónaállományok és a parancssoros keze- 
lés. A kedvenc , visszatérés a gyökerekhez" mozgalom ered- 
ményeként található ez a segédprogram az ingyenes Sup- 
port Tools-ban. Szinte minden feladat elvégezhető vele, 
anélkül hogy a bűnös GUI-val kéne találkoznunk. Csak Win- 
dows 2000 DNS kiszolgálókkal működik együtt - az NT4 Re- 
source Kit-ből ismert DNSStat utódjaként. 


dnscmd kiszolgáló parancs [paraméterek] 


A kiszolgáló címzése három módon is megoldható: 1. IP cím, 
2. DNS név (teljes tartománynév, FODN) , 3. NETBIOS név alap- 
ján. Az első kettő TCP/IP-n keresztüli RPC hívásokkal operál, 
míg a harmadik Named Pipes-on keresztül RPC-zik. A helyi ki- 
szolgálót is elérhetjük. A jogosultságok szempontjából a be- 
jelentkezett felhasználót veszi csak figyelembe. 
A parancsok nagyon sokrétűek: csak képzeljük el, hogy a teljes 
grafikus DNS menedzser funkcionalitását kellett belesűríteni eb- 
be a 83 Kbyte-ba. A munka szintjeként választhatjuk a teljes 
DNS kiszolgálót, bizonyos zónákat, és tartományokat. Az általá- 
nos kiszolgáló-lekérdezést a /Info kapcsolóval, a zónalekérde- 
zést /Zoneinfo kapcsolóval tehetjük meg. Itt jegyezném meg, 
hogy a paraméterek mind betűméret-érzékenyek - nem hajtód- 
nak végre a lekérdezések, beállítások, ha nem a szintaxisban 
leírtak szerint választjuk meg a nagybetű-kisbetű kombináció- 
kat. Ezen parancsok további paramétereket is támogatnak - fő- 
leg mivel a zónákkal való műveleteknél a parancs mögött meg 
kell adni a zóna nevét teljes tartománynév (FODN) formában. 
A parancsok (nem teljes) listája: 
"0 ResetForwarders - a továbbkérdezéshez használt DNS 
kiszolgálók adhatóak meg 
"0 ResetListenAddresses - a kiszolgáló IP címei közül me- 
lyiken működjön a DNS szolgáltatás 
"0 ZoneAdd - új zóna létrehozása 
"0 ZoneResetlype - a zóna typusának változtatása (elsőd- 
leges, másodlagos, AD integrált) 
"8 RecordAdd - új bejegyzés felvétele (A, SOA, NS, CNAME, 
MX, SRV) 
"0 Restart - a DNS kiszolgáló-szolgáltatás újraindítása 
A komolyabb, scriptalapú DNS manipulációkat a Resource Kit 
Perl eszközeivel (DNSZones, DNSRecord, DNSServer) csináljuk. 
Akik még meredekebben, egyéni eszközök, scriptek létreho- 
zását célozták meg, a DNSPROV segíthet (szintén a Resource 
Kit-ből), mivel segítségével WMI szolgáltatóként a DNS ki- 
szolgáló a WMI Platform SDK alapján kezelhetővé válik. 


Apróságok 
Ki is vagyok én? Ezt a filozofikus kérdést néha elmormolja a 
rendszergazda, miközben egy felhasználó gépén próbál életet 
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lehelni egy jogosultságokon elhasalt programba. Hol vagy jó 
öreg Novell Netware, hol a Whoami parancs? Ez a programocs- 
ka a Resource Kit lakója. Paraméterezése végtelenül egyszerű. 
Ha paraméter nélkül futtatjuk, a válasz a parancsot lefuttató 
felhasználó neve és tartományi hovatartozása lesz. Ha a /all 
kapcsolót használjuk, megkapjuk többek közt a csoporttagsá- 
gokat, és a rendszerszintű jogokat (pl. rendszer leállítása tá- 
volról) is. A SID - azaz a Windows 2000 felhasználók, objek- 
tumok egyedi biztonsági azonosítója is kiíródik, ha valaki ez 
alapján szeretne mondjuk AD-t buherálni, debugolni. 

(Ha csak a bejelentkezett felhasználóra vagyunk kíváncsiak, és 
nincs kéznél a Whoami, akkor a set /find "username" paranccsal 
is célt érhetünk el. A szerk.) 


Floppy meghajtó zárolása 

A felhasználók kontárkodási esélyeit radikálisan megnyirbálhat- 
juk, ha a Resource Kit FloppyLock szolgáltatás fut a munkaállo- 
máson. Ilyenkor csak a Rendszergazdák és a Kiemelt Felhaszná- 
lók (Administrator és Power Users) tudnak a floppyhoz hozzáfér- 
ni. Server esetében ez csak a Rendszergazdákra vonatkozik. A 
FloppyLock szolgáltatást telepítenünk kell minden megvédendő 
gépre. A telepítéshez a szintén Resource Kit lakó grafikus felü- 
letű Service Installation Wizard, vagy a parancssoros instsrv.exe 
használható. A telepítése során a , FloppyLock" nevet, az állo- 
és a szolgáltatás típusát (service) kell megadni. Ha a kedves fel- 
használó megpróbál ezek után floppyhoz nyúlni, a jól ismert 
Hozzáférés megtagadva" üzenettel fog szembesülni. 


Terminálkapcsolatban a kliensgép meghajtóinak auto- 
matikus megosztása 

A hagyományos terminálkliens funkció bővíthetőségét már az 
előző részben is tárgyaltam - akkor a kliens és szerver közötti 
állományműveleteket kivitelezését boncolgattam. Most egy 
másik, szintén hasznos funkcióbővítést vettem elő, amely lehe- 
tővé teszi, hogy a terminálkapcsolat létrejöttekor a kliensgép 
összes meghajtója automatikusan felcsatolva ott legyen a ter- 
minálkiszolgáló Windows felületében. Ezáltal az állományátvi- 
tel még egyszerűbben zajlik, amihez mindössze egy-egy állo- 
mányt kell bemásolnunk a rendszerekbe, és egy-egy regisztrá- 
ciós adatbázis-módosítást kell automatizáltan megtennünk. El- 
ső lépésként a terminálkiszolgáló SYSTEM32 könyvtárába má- 
soljuk be a drmapsrv.exe-t, majd illesszük be a regisztrációs 
adatbázisba a drmapsrv.reg-et a jobbklatty-merge kiválasztásá- 
val. A kliensen a drmapclt.dil-t kell a Terminal Service Client 
könyvtárba bemásolni, majd a drmapclt.reg-et a regisztrációs 
adatbázisba beolvasztani. Ezek után a manuális megosztás-fel- 
csatolás helyett a kánaáni automatizáció előnyeit élvezhetjük. 


Radvánszki Gábor 
gabor oradvanszki.net 
MCP 


[ab eti 3 rar G HL 1ETI 
[1] http://support.microsoft.com/support/kb/articles/ 
4 0272/4/72.asp 
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Előző havi cikkemben a tűzfalakról írtam. Az ott leírtak sokszor 
vissza fognak köszönni a cikksorozatban, és - ha el nem felej- 
tem - próbálok is majd utalni rájuk. Az e havi cikk, ígéretem- 
től eltérően, még nem tartalmaz konkrét , így kattintsunk" jel- 
legű dolgokat, erre a következő cikkig még várni kell. A most 
következő oldalakon próbálom megismertetni a Kedves Olvasót 
az ISA Server-rel. Ez több szempontból is fontos. Egyrészt 
azért, mert a későbbiekben minden igyekezetem ellenére sem 
fogom tudni az összes funkciót a teljes részletességgel leírni, 
de szükségesnek tartom, hogy bemutassam (legalább dióhéj- 
ban) az ISA-ban rejlő összes lehetőséget (vagy legalábbis ezek 
nagy részét) . Másrészt szeretném, ha mindenki elkülönítené az 
ISA Server-t a Proxy Server 2.0-tól. Az ISA Server 2000 egy 
nagy teljesítményű tűzfal és web gyorsítótár, melyet úgy ter- 
veztek, hogy nagyvállalati környezetben is megállja a helyét, 
és még a legkényesebb igényeket is kielégítse. Természetesen 
az ISA is a Windows 2000-re épül, és maximálisan kihasznál- 
ja az operációs rendszer adta lehetőségeket (például bizton- 
sági beállítások, rendszerfelügyelet és címtár), hogy megvaló- 
sítható legyen az internetelérés házirendalapú felügyelete, és 
a rendelkezésre álló sávszélesség optimális kihasználása. 
0 Biztonság: az ISA Server tűzfalként megakadályozza a 
hálózatok jogosulatlan elérését, védi az internetről 
elérhető kiszolgálókat a külső támadásoktól és termé- 
szetesen ellenőrzi az összes rajta átmenő forgalmat. 
Optimális sávszélességkihasználás: az ISA is, mint álta- 
lában a proxy tűzfalak, tartalmaz gyorsítótárat. Ennek se- 
gítségével gyorsabb webelérést biztosít, mert a kérések 
egy részét az internet helyett a helyi gyorsítótárból szol- 
gálja ki. A hálózati forgalom csökkenése miatt csökkent- 
hetők az internetelérésre fordított költségek. Reverse pro- 
xy-ként működve csökkenti a webkiszolgálók terhelését. 
Rendszerfelügyelet: a felhasználók internethozzáférésé- 
nek szabályozása házirendek kikényszerítésével. A cég 
szempontjából hasznos alkalmazásokra és weboldalakra kor- 
látozható az Internet használata, ezzel növelhető a terme- 
lékenység (mert ha a mélyen tisztelt dolgozó nem nézegethe- 
ti az XXX-es oldalakat, az így keletkezett , szabadidőben" akár 
dolgozhat is :) ). A sávszélesség üzleti érdekek szerint oszt- 
ható el a felhasználók között, s az internethasználatról je- 
lentések készíthetők. Ezek pedig nagyon fontosak a jövőbe- 
ni fejlesztések meghatározása szempontjából. 

8 Testreszabhatóság: az ISA Server tűzfal és gyorsítótár- 
összetevői a vállalat igényeitől és hálózatának felépítésé- 
től függően külön gépekre is telepíthetők (de természete- 
sen futhatnak ugyanazon a gépen is). A fizikai kiépítéstől 
függetlenül - a Windows 2000 képességeit kihasználva — 
az ISA Server-ek egységes rendszerként képesek működni 
(például ugyanazt a házirendet kényszerítik ki). 


Ve, 


o 


A fent említetteken túl az ISA Server-hez gazdag SDK és API 
készlet tartozik, melyek segítségével például a következő terü- 
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leteken bővíthető az ISA funkcionalitása: felügyelet, vírusszű- 
rés, tartalomszűrés, bizonyos webhelyek elérésének megakadá- 
lyozása, alkalmazásszűrők, valósidejű megfigyelések, stb. 


A .NET nagyvállalati kiszolgálók 

Jogos a kérdés, hogy hogyan is illeszkedik az ISA a .NET , kép- 
be". Jól! Sőt, merem állítani, hogy az ISA kulcsfontosságú tag- 
ja a .NET családnak. Miért is? Mint tudjuk, a .NET kiszolgálók 
alkotják a Microsoft minden igényt kielégítő alkalmazáskiszol- 
gáló családját. E kiszolgálók felhasználásával skálázható, in- 
tegrált, könnyen felügyelhető webalapú megoldások és szol- 
gáltatások készíthetők és helyezhetők üzembe. Mindez azon- 
ban fabatkát sem érne a biztonság nélkül. Én például nem bíz- 
nám a személyes adataimat, ne adj" isten a pénzem egy olyan 
kiszolgálóra, amelyet csak úgy , rádugtak az Internetre". 


Egyszerű rendszerfelügyelet -- átlátszóság a felhaszná- 
lók számára - Alacsonyabb TCO 

A biztonság és a gyorsítótár külön felügyelete általában kü- 
lönféle eszközöket, infrastruktúrát és tapasztalt rendszer- 
gazdákat igényel. Ezzel nő a rendszer összetettsége, üze- 
meltetési költsége - és kompatibilitási problémák adódhat- 
nak. Az ISA Server egységes, házirendalapú felügyeleti esz- 
köze segít a rendszergazdáknak egy központi helyről elvé- 
gezni a beállításokat, így javul a hálózat átláthatósága, és 
csökken a teljes birtoklási költség. A vállalatoknak előnyö- 
sek a tűzfal és gyorsítótár ellentmondásmentes szabályai. A 
Windows 2000 által biztosított integrált felügyeleti rendszer 
biztosítja ezen szabályok együttes megjelenítését, így a tűz- 
fal és gyorsítótár infrastruktúra egyszerre felügyelhető. 

A kiváló felügyeleti lehetőségek mellett a vállalatok a könnyű 
üzembehelyezhetőséget is igénylik. Az ISA Server-rel csak a 
tűzfal és a gyorsítótár kiszolgálók beállítására van szükség, így 
egyszerűsödik a kiszolgálók közzététele, a tűzfal és a gyorsító- 
tár beállítása. Az ISA Server biztonságos címfordítási (Secure 
Network Address Translation — SecureNAT) képességének hasz- 
nálatával a rendszergazdáknak nem kell további szoftvert tele- 
píteni az ügyfélgépekre vagy a közzétett kiszolgálókra a tűzfal 
vagy a gyorsítótár használatához. Az ISA Server láthatatlan az 
ügyfélgépek és más kiszolgálók számára, így csökkenthetők a 
rendszerfelügyelet összetettsége és költségei. 

És egy kis realitás: 

Ne feledkezzünk el arról sem, hogy a könnyű felügyelhető- 
ség - bár igen fontos - nem pótolhatja a szakértelmet, és 
nem egyenlő a biztonsággal. 
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BIZTONSÁG ISA SERVER - AZ ALAPOK 
Az ISA Server üzemmódjai 

Az ISA Server háromféle üzemmódban működhet: tűzfal, 
gyorsítótár és integrált (tűzfal és gyorsítótár ugyanazon a 
gépen) módban. 


Internet tűzfal 

Az ISA Server üzembehelyezhető tűzfalként, amely az Inter- 

net és a belső ügyfélgépek közti biztonságos átjáróként mű- 

ködik. Az ISA Server a kommunikációban résztvevők számá- 

ra észrevétlen. A felhasználó egész addig nem is veszi ész- 

re, hogy a tűzfal jelen van, amíg nem próbál olyan szolgál- 

tatást vagy webhelyet elérni, aminek az ISA tiltja a haszná- 

latát. A biztonsági házirendek beállításával megelőzhető a 

hálózat illetéktelen használata, a veszélyes dolgok hálózat- 

ra kerülése, és letiltható a kifelé irányuló forgalom, például 

a felhasználó vagy felhasználói csoport, az alkalmazás, a 

kapcsolat célja, a tartalom típusa vagy a napszak szerint. 

Az ISA Server ezt megvalósító fő szolgáltatásai: 

"0 többrétegű tartalomfigyelés - csomag-, kapcsolat- és 
alkalmazásszűrők 

"9 ,Intelligens", adatfelismerő alkalmazásszűrők 

-? beépített behatolásészlelés 

"0 a rendszer megerősítése a Windows 2000 biztonságo- 

sabbá tételéért 

beépített virtuális magánhálózat (VPN) lehetőségek 


Ma 


Biztonságos kiszolgáló közzététel 
Az ISA a belső hálózat biztonságának veszélyeztetése nélkül 
biztosítja a szolgáltatások Interneten való közzétételét. Beál- 
líthatók a web és más kiszolgálók közzétételének szabályai, 
melyek eldöntik mely kérések továbbítódnak az ISA Server mö- 
gött található kiszolgálók felé. Ezzel biztosított a belső kiszol- 
gálók biztonsága. Például egy Microsoft Exchange kiszolgáló 
elhelyezhető az ISA Server mögött, és beállíthatók a kiszolgá- 
ló közzétételének szabályai, melyek lehetővé teszik az Inter- 
neten való közzétételt. Az Exchange Server-re bejövő leveleket 
elfogja az ISA Server, amely az ügyfelek számára levelező ki- 
szolgálónak látszik. Az ISA Server képes megszűrni a forgal- 
mat, majd továbbítani az Exchange Server-nek. Magát az Ex- 
change Server-t nem is láthatják a külső felhasználók, így az 
végig biztonságos környezetben marad. 
Az ISA Server kiszolgáló közzétételt elősegítő szolgáltatásai: 
"0 könnyen használható kiszolgáló közzététele varázslók 
"8 SecureNAT 
"0 széleskörű protokoll-támogatás (például HTTP, FTP, 
H.323, SMTP, folyamatos átviteli szolgáltatások) 


Belső ügyfeleket kiszolgáló gyorsítótár 

Az ISA Server telepíthető belső ügyfeleket kiszolgáló gyorsító- 

tárként, amely azoknak Internet elérést biztosít. Az ISA Server 

az Internetről letöltött objektumokat egy központi gyorsítótár- 

ba helyezi, amelyet bármely webböngésző elérhet. A tartalom 

helyi meghajtóról való , szállítása" természetesen sokkal keve- 

böngészőjének teljesítményét, csökkenti a válaszidőt, boldogít- 

ja a felhasználót és csökkenti az internetkapcsolat használatát. 

Az ISA Server fő gyorsítótár szolgáltatásai: 

8 a gyorsítótár egy része a rendszermemóriában helyez- 
kedik el 

"0 időzített letöltések 
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(II.RÉsz) 
"0 elosztott és hierarchikus gyorsítótár láncok létrehozá- 
sának támogatása 

a népszerű webhelyek tartalmának előzetes letöltése 
(Active Caching) 


8 


Külső ügyfeleket kiszolgáló gyorsítótár (reverse proxy) 

Az ISA Server telepíthető a webes alkalmazásokat futtató web- 
kiszolgálók elé. A bejövő webkérésekre az ISA webkiszolgáló- 
szolgálja ki, csak azokat a kéréseket továbbítva a webkiszolgá- 
ló felé, amelyeket nem tud gyorsítótárából kiszolgálni. 

Az ISA Server fő reverse proxy szolgáltatásai: 

) webközzététel varázslók 

-B a gyorsítótár egy része a rendszermemóriában helyez- 
kedik el 

az összes ügyfél számára láthatatlan 

elosztott gyorsítótár kialakítása a Cache Array Routing 
Protocol (CARP) segítségével 


6 


Integrált tűzfal és web gyorsítótár kiszolgáló 

Ez tulajdonképpen a fenti funkciók összevonása egyetlen ki- 
szolgálóra. Elsősorban kis és közepes méretű vállalatok számá- 
ra ajánlott megoldás, a nagyvállalati rendszerekben - teljesít- 
ményszempontok miatt - ajánlott a funkciók szétválasztása. 






Internet 


6 ISA Server integrált üzemmódban 


Felügyelet - a házirendek és szabályok alapjai 

A Microsoft ISA Server-t az egyszerű üzemeltetés érdekében 
kiváló felügyeleti képességekkel ruházták fel. A gyorsítótá- 
rak és tűzfalak központi helyről történő felügyelete növeli a 
biztonságot, a szabályozások következetességét, és leegy- 
szerűsíti a rendszer felügyeletét. Ez ugyanúgy igaz a Small 
Business Server-ben található ISA Server-re, mint a több 
fiókiroda között létrehozott kiszolgálóláncokra, vagy akár 
egy Internet szolgáltatónál kiépített ISA Server tömbre. 

Az alábbiakban a legfőbb eszközök áttekintése következik, 
melyek segítségével biztonságosan szabályozhatók a befelé 
és kifelé irányuló kérések, és az azokra érkező válaszok. 


Házirendek 

Beállítható szabályok, melyek a helyi hálózat és az Internet 
közti kommunikációt szabályozzák. Ezek a szabályok válla- 
lati vagy kiszolgálótömb szintű házirendekben adhatók 
meg, és központilag tárolódnak az Active Directoryban. 


Kiszolgálótömb házirend vagy vállalati házirend? 

Tömbszinten webhelyre, tartalomra, protokollra, webköz- 
zétételre vonatkozó szabályok, és IP csomagszűrők készít- 
hetők. E szabályok együttese alkotja a tömb házirendjét. A 
tömb házirendje meghatározza, hogy az ISA Server ügyfe- 
lek hogyan kommunikálnak az Interneten, és mely kommu- 
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nikáció van számukra engedélyezve. A tömbházirend csak 
az adott tömbben levő ISA Servereken érvényesül. 
Készíthető vállalati házirend is, mely webhelyre, tartalomra 
és protokollra vonatkozó szabályokat tartalmaz. A vállalati 
házirend bármely tömbre érvényesíthető, és kibővíthető a 
tömb saját házirendjével. Ez teszi lehetővé a fiókirodák és 
osztályok rendszergazdáinak a vállalati házirendek átvételét. 
A tömbházirendek csak szigorúbbak lehetnek a vállalati 
házirendnél, ami azt jelenti, hogy a tömbszintű házirendek 
segítségével finomhangolható a vállalati házirend, de csak 
további tiltásokat tartalmazhatnak. 


Az ISA Server szabályainak bemutatása 

Az ISA Server egyéni biztonsági igényeket is kielégíthet olyan 
szabályok megadásával és beállításával, melyek eldöntik, hogy 
mely felhasználók, szolgáltatások, portok és tartományok hoz- 
záférése engedélyezett a helyi hálózat, vagy az Internet szá- 
mítógépein. Az ISA Server-ben háromféle szabály adható meg: 
"0 a hozzáférések házirendjének szabályai 

0 sávszélességszabályok 

"0 közzétételi szabályok 


A hozzáférések házirendjének szabályai 

Az ISA Server használható a hozzáférések házirendjének 

beállítására, mely webhely-, tartalom- és protokollszabá- 

lyokból valamint IP csomagszűrőkből áll: 

0 A webhely- és tartalomszabályok megadják, hogy mely 
webhelyek érhetők el az ISA mögött elhelyezke- 
dő ügyfelek számára. Ezek alkalmazásszinten kerülnek 
feldolgozásra. 

"0 A protokollszabályok megadják az ISA Server mögötti 
felhasználók által használható protokollokat. A proto- 
kollszabályok alkalmazásszinten kerülnek feldolgozásra. 

0 AzIP csomagszűrők engedélyezik vagy megakadályoz- 
zák a beállított IP címek között megadott protokollt, 
és portokat használó kommunikációt. Az IP csomag- 
szűrők csomagszinten kerülnek feldolgozásra. 


Sávszélességszabályok 

Az ISA Server sávszélességszabályai a Windows 2000 00S 
(Ouality of Service, garantált szolgáltatásminőség) képessé- 
geire épülnek, hogy meghatározhassák, mekkora sávszéles- 
ség osztható ki egy adott Internet kérésnek. A sávszéles- 
ségszabályok alkalmazásszinten kerülnek feldolgozásra. 


Közzétételi szabályok 

A kiszolgálóközzétételi szabályok szűrik az összes bejövő és 
kimenő kérést. A bejövő kéréseket a megfelelő ISA Server 
mögötti kiszolgálóhoz rendelik hozzá. Például az Exchange 
Server 2000 a külső felhasználók számára érzékelhetetlenül 
tehető elérhetőve az ISA Server-en keresztül. A webközzé- 
tételi szabályok pedig a bejövő kéréseket a megfelelő ISA 
Server mögötti web kiszolgálókhoz rendelik hozzá. 


A házirend alkotóelemei 

A házirend alkotóelemei a szabályok. Aprólékos szabályo- 
zást tesznek lehetővé nemcsak telephelyenként vagy fel- 
használónként, hanem pédául a sávszélesség elosztásán, 
megadott protokollokon és tartalomtípus szerint is. Mint 
az ISA Server legtöbb része, az egyedi igények kielégítése 
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érdekében a házirend elemei is bővíthetők. A vállalatok 

például vásárolhatnak tiltott URL-eket tartalmazó listákat 

erre szakosodott cégektől, melyek beilleszthetők a házi- 
rend alkotóelemei közé. Az egyes elemek a következők: 

"B az időzítések meghatározzák, hogy mely időpontokban 
engedélyezett vagy tiltott az ügyfelek hozzáférése. 

"8 a sávszélességelsőbbségek meghatározzák a befelé és 
kifelé irányuló forgalom súlyozását az elérhető sáv- 
szélesség jobb kihasználása érdekében 

"8 a célállomás csoportok távoli webhelyeket definiálnak 
IP cím vagy URL alapján 

"8 az ügyfélcím csoportok belső ügyfeleket határoznak 
meg IP cím, vagy a tartomány felhasználói fiókjai, 
felhasználói csoportjai alapján 

"8 a protokolldefiníciók protokollok szerint finomítják a 
szabályokat 

"8 a tartalomcsoportok a leggyakoribb fájltípusok logi- 
kai csoportjai (például video, audio, képek) 


Az ISA Server konzol 

Minden felügyeleti, megfigyelő és jelentéskészítő eszköz a 
felügyeleti alkalmazásból érhető el. Ez a program a közis- 
mert Microsoft Management Console-t használja. Azt hi- 
szem, az MMC használatát nem is kell részleteznem. 





5 , Valahol már láttam..." :) 


Windows 2000 integráció és felügyelet 

Az ISA Server kihasználja a Windows 2000 és Active Directo- 
ry által biztosított felügyeleti lehetőségeket. Ezzel egyszeri 
bejelentkezés válik lehetővé. Lerövidül a változtatások fel- 
használókhoz való eljutásának ideje, és a felhasználói fiók- 
ban tárolt információk felhasználhatók arra, hogy az ISA Ser- 
ver segítségével engedélyezzék vagy letiltsák a felhasználó 
bizonyos Internetes szolgálattásokhoz való hozzáférését. 

Az operációs rendszerrel való integráltság kihasználásának 
másik példája a Windows 2000 Server Performance Monito- 
ra, mely számos ISA Server jellemző valósidejű mérését le- 
hetővé teszi. A Windows 2000 eseménynaplója segít követni 
az ISA Server-rel kapcsolatos eseményeket, és segít a hiba- 
elhárításban. A távoli adminisztráció pedig az MMC és/vagy 
a Terminal Services használatával valósítható meg. 

Az ISA Server rugalmas, jól testreszabható felügyeleti modult 
tartalmaz, így csökkentheti a tűzfal, a gyorsítótár és a sávszé- 
lességszabályzó eszközök felügyeletének bonyolultságát. 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 06. 





22 


23 


BIZTONSÁG ISA SERVER - AZ ALAPOK 
SecureNAT ügyfelek 

Azokat az ügyfélszámítógépeket, melyekre nincs tűzfal ügyfél- 
szoftver telepítve, SecureNAT ügyfeleknek nevezzük. A Secure- 
NAT ügyfelek használhatják az ISA Server legtöbb funkcióját, 
így például a hozzáférést szabályozó funkciók nagy részét is, ki- 
véve a magasszintű protokolltámogatást és a felhasználónkén- 
ti hitelesítést. A SecureNAT használatakor az ügyfélszámítógé- 
pek semmilyen beállítást nem igényelnek, így az ISA Server 
üzembe helyezése és menedzselése a felhasználók számára ész- 
revétlen, a rendszergazdák számára pedig sokkal egyszerűbb. 
Bár a SecureNAT ügyfelek semmilyen különleges szoftvert 
nem igényelnek, az alapértelmezett átjárót úgy kell rajtuk 
beállítani, hogy az összes Internet felé irányuló forgalom 
az ISA Serveren haladjon át. Az ISA Server is beállítható 
alapértelmezett átjáróként, de ez nem követelmény. 


A SecureNAT és a Windows 2000 NAT 

Az ISA Server az ISA Server házirendek SecureNAT ügyfelek- 

re való kikényszerítésével bővíti ki a Windows 2000 címfor- 

dítási (NAT) képességeit. Más szóval, a SecureNAT nagyobb 
biztonságot és jobb szabályozhatóságot nyújt, mert a tar- 
talmak áthaladnak az alkalmazásszűrőkön, valamint a házi- 
rendek és a sávszélességszabályzás is érvényesül rajtuk. 

Minden ISA Server szabály (protokollhasználat, célállomások 

és tartalom típusa) alkalmazható a SecureNAT ügyfelekre, 

annak ellenére, hogy a Windows 2000 NAT nem tartalmaz 
beépített hitelesítési eljárást. 

Mivel a SecureNAT ügyfelek kéréseit főként a tűzfalszolgál- 

tatás kezeli, a SecureNAT ügyfelek a következő biztonsági 

előnyökkel bírnak: 

"b Az alkalmazásszűrők képesek megváltoztatni az adatfo- 
lyamot, hogy átjuthassanak az összetett protokollok. A 
Windows 2000 NAT-nál ez NAT szerkesztők (NAT Editor) 
használatával valósítható meg, melyeket kernelmódú NAT 
szerkesztő meghajtóként írtak meg a Windows 2000-hez. 

"0 Atűzfalszolgáltatás átadja a HTTP kéréseket a web pro- 
xy szolgáltatásnak, amely a gyorsítótárat kezeli, és 
biztosítja a webhely és - tartalom szabályok megfelelő 
alkalmazását. 


Tűzfal ügyfelek 

A tűzfal ügyfélprogram telepítése lehetővé teszi a hozzáfé- 
rési házirendek hitelesített felhasználókra való alkalmazá- 
sát is (nemcsak az ügyfélszámítógépek IP címeire) . Így pél- 
tünk bizonyos Windows NT vagy Active Directory tartomá- 
nyi felhasználókra és felhasználói csoportokra, amelyek 
NTLM vagy Kerberos jegyek segítségével lettek hitelesítve. 
A tűzfal ügyfél támogatja a WinSock alkalmazásokat is. A tűzfal 
ügyfél telepítése nem változtat a WinSock alkalmazások 
beállításain, hanem ugyanazt a WinSock dll fájlt használ- 
ja, amit az alkalmazások. A tűzfal ügyfél elfogja az alkal- 
mazások hívásait, és eldönti, hogy továbbítsa-e a kérést 
az ISA Server számítógépnek. 

A tűzfal szolgáltatás az 1.1-es és 2.0-s WinSock verziót 
használó alkalmazásokat támogatja. Mielőtt egy WinSock 
alkalmazás hozzáférhetne az ISA Server-en keresztül az 
Internethez, a kiszolgálót is be kell állítani, hogy enge- 
délyezze a felhasználónak a szükséges protokoll és a szük- 
séges szolgáltatás portok használatát. 
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A tűzfal ügyfél Windows 95, Windows 98, Windows NT 4.0 vagy 
Windows 2000 operációs rendszert futtató gépekre telepíthető. 


A SecureNAT ügyfelek és a tűzfal ügyfelek 

Az ISA Server biztosítja az összes tűzfal és SecureNAT ügyféllel 
folytatott hálózati kommunikáció biztonságosságát, emellett 
minden ügyfél élvezi az ISA Server gyorsítótárának előnyeit. 
Mind a SecureNAT, mind a tűzfal ügyfelek védhetők alkalma- 
zásszűrőkkel, melyek tartalomellenőrzést és más biztonsági 
tevékenységeket végeznek. Ha az IP továbbítás elérhető, a 
jobb teljesítmény és késleltetés eléréséhez mindkettő hasz- 
nálhatja a kernel módban futó , adatszivattyút" (data pump). 


Biztonságos web- és kiszolgálóközzététel 

Az ISA Server a belső hálózat biztonságának veszélyeztetése 
nélkül biztosítja az Internetre való közzétételt. A web- és ki- 
szolgálóközzétételi szabályok beállíthatók arra, hogy eldönt- 
sék mely kéréseket kell beküldeni az ISA Server mögött levő ki- 
szolgálónak. A közzétett kiszolgáló külvilág felé való megsze- 
mélyesítésével az ISA Server a nagyobb biztonságot és a gyor- 
sítótárba helyezett webtartalom gyorsabb elérését biztosítja. A 
közzétett belső kiszolgálón nem szükséges további szoftvere- 
ket telepíteni, mert az ISA Server a SecureNAT-ot használja a 
felhasználó számára észrevétlen kommunikációhoz. 


Kiszolgáló közzététel 

Egy belső Microsoft Exchange Server például SMTP leveleket 
küld és fogad az Internetről. Mivel az SMTP mind a bejövő, 
mind a kimenő kommunikációhoz a 25-ös portot használja, 
az Exchange Server az ISA Server külső címének 25-ös port- 
jához van kapcsolva. Ily módon az Exchange Server felé irá- 
nyulhatnak bejövő kapcsolatok. A közzététel ezen módjának 
megvalósításához készíteni kell egy vagy több kiszolgáló- 
közzétételi szabályt, melyek megadják, hogy mely belső ki- 
szolgálóknak engedélyezett az Interneten való megjelenés. 
Az ISA Server egy vagy több kiszolgáló nevében figyeli a ké- 
réseket, és átirányítja azokat a megfelelő kiszolgálóhoz. 


Címfordítás 








Internet 
Kiszolgáló 


5 Kiszolgáló közzététele 


Webközzététel 

A webkiszolgáló az ISA Server mögé helyezhető. A webközzé- 
tételi szabályok teszik lehetővé a webkiszolgáló Interneten va- 
ló , megjelenítését". A webkiszolgáló felé irányuló bejövő ké- 
réseket az ügyfelek felé webkiszolgálóként megjelenő ISA Ser- 
ver a gyorsítótárából szolgálja ki, és csak akkor továbbítja a 
kéréseket a belső kiszolgáló felé, ha azok a gyorsítótárból nem 
szolgálhatók ki. Eközben a webkiszolgáló biztonságos körny- 
zetben van, és elérheti a belső hálózati szolgáltatásokat. 
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Az ISA Server megszemélyesíti a webhelyet, mivel az ő IP cí- 
me az egyetlen, amelyhez DNS név (Host rekord) tartozik. A 
webközzétételi szabály továbbítja a kéréseket a belső háló- 
zat megfelelő webkiszolgálója felé. Az ISA Server átveszi a 
webtartalom feldolgozásának egy részét, biztonságot jelent, 
központi SSL kulcsfelügyeleti helyet biztosít és lehetővé te- 
szi több kiszolgáló egy webhelyként való közzétételét. 


Web proxy 









Gyorsítótár 


Internet 
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A rendszer megerősítése 

A tűzfalnak biztonságosnak kell lennie, hiszen minden táma- 
dás során ő a ,pofozózsák". Nyilvánvalóan védi saját magát 
is, de azért sosem árthat, ha az operációs rendszer, amin a 
tűzfal fut, mentes a biztonsági résektől. Ezt segíti elő az ISA- 
ban található System Hardening Wizard, amivel az ISA szerep- 
körének megfelelő biztonsági mintát húzhatjuk rá tűzfalunk- 
ra. Vigyázat! Ez nem csodaszer! A biztonsági minták tartal- 
mazzák ugyan a Windows 2000 biztonsági szolgáltatásainak 
megfelelő beállításait, de a folyamatosan megjelenő hibajaví- 
tásokat nem. Ha valahol, hát az ISA-nál igazán fontos ezek 
folyamatos követése, és a kiszolgáló naprakészen tartása. 


Az ISA, mint webgyorsítótár 

A legtöbb webböngésző támogatja az objektumok helyi gyor- 
sítótárba helyezését, ami azt jelenti, hogy az ügyfélgépen tá- 
rolódnak a lekért weblapok. Ha ezt egy kicsit továbbgondol- 
juk, szinte adja magát az ötlet, hogy legyen egy olyan köz- 
ponti gyorsítótár, amely lehetővé teszi, hogy az Internet fe- 
lől jövő dróton ezek az anyagok csak egyszer menjenek át, 
ne kelljen mégegyszer megtennünk ezt - ha már egyszer le- 
töltöttük őket. Ez persze így túl egyszerű volna. Egyrészt, 
mert idővel az egész Internet a merevlemezeinken lenne :), 
másrészt egy idő után rengeteg fölösleges és elavult dolgot 
találnánk itt. Mint az előző részben már említettem, az alkal- 
mazásszintű ellenőrzés eléggé processzorigényes feladat, vi- 
szont a HTTP és FTP objektumok biztosítása az ISA Server 
memóriájából vagy merevlemezéről sokkal kevesebb feldol- 
gozást igényel, mint az Internetről jövők (mert hát minek is 
ellenőriznénk újra meg újra azokat a dolgokat, amiket egyszer 
már ellenőriztünk?) . Akár a befelé, akár a kifelé irányuló ké- 
réseket kiszolgáló gyorsítótárként alkalmazzák, az ISA Server 
gyorsítja a böngészést, csökkenti a válaszidőket és optimali- 
zálja a sávszélesség kihasználását. 


A gyorsítótár tartalmának időzített letöltése 

Az ISA Server képes a gyorsítótárba meghatározott tartal- 
makat időzítetten letölteni. Egy háttérben futó folyamat 
előre beállított időzítés szerint mindig akkor tölti le a tar- 
talmakat, amikor az ISA Server éppen nem kezel web pro- 
xy ügyfelektől érkezett kéréseket. 

A gyorsítótár tartalmának időzített letöltése lehetővé teszi, 
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hogy az ISA Server a várhatóan hamarosan kért HTTP tarta- 
lommal frissítse a gyorsítótár tartalmát (ilyenek lehetnek pél- 
dául a hír-weblapok) . Ha okosan használják, az időzített letöl- 
tés értékes sávszélességet takarít meg, és az átbocsátóképes- 
ség befolyásolása nélkül növeli a gyorsítótár teljesítményét. 
A gyorsítótár tartalmának időzített letöltése egy Windows 
2000 szolgáltatás (service). Éppen úgy meg lehet állítani, 
elindítani, szüneteltetni, mint bármely hasonló szolgáltatást. 


Elosztott gyorsítótárak 

Az ISA Server egyik leghasznosabb képessége az elosztott 
gyorsítótárak használatának támogatása. Ez a képesség teszi 
alkalmassá az ISA Server-t a nagyvállalatok és Internet szol- 
gáltatók rendkívül nagy igényeinek kielégítésére. A gyorsító- 
tár objektumainak terheléselosztása növeli a gyorsítótár tel- 
jesítményét, és emellett hibatűrést is biztosít. Az elosztott 
gyorsítótárak használata gyorsítótár tömbök vagy láncok, 
vagy a kettő kombinációjának létrehozásával lehetséges. 

Az elosztott gyorsítótárak használata azért fontos, mert így a 
gyorsítótárak közelebb kerülnek a felhasználókhoz. Egy nagy- 
vállalaton belül a gyorsítótár láncok például a vállalati háló- 
zat határától (egy központi helytől) egészen a fiókiroda, vagy 
munkacsoport szintig lenyúlhatnak. Egy Internetszolgáltató 
hálózatán belül a gyorsítótárak a szolgáltató helyi megjelené- 
si pontjaitól a központi megjelenési pont felé húzódnak. 

A gyorsítótárak felhasználókhoz való közelebb helyezésé- 
vel csökkenthető a hálózati forgalom és a költségek, és nö- 
velhető a teljesítmény. 

A Microsoft ISA a több ISA Server-ből álló tömbök létreho- 
zását a Cache Array Routing Protocol használatával támo- 
gatja. Ez a gyorsítótár objektumok terheléselosztásával ja- 
vítja az aktív és passzív gyorsítótárak teljesítményét. 





Tűzfal 
Gyorsítótár Gyorsítótár 
Internet 


Tűzfal 
a. Gyorsítótár 
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Cache Array Routing Protocol — skálázhatóság — 

A Microsoft azért fejlesztette ki a CARP-ot, hogy ennek se- 
gítségével kommunikáljanak egymással az ISA Server számí- 
tógépek egy láncban vagy egy tömbben, és hatékony, skáláz- 
ható gyorsítótárak együttesét alkossák. A CARP megoldja a 
gyorsítótárak használatának hatékonysági problémáit. Más 
gyorsítótár megoldásokkal ellentétben a CARP elosztott irá- 
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nyítási eljárást használ a lekérdezések helyett a tárolt Inter- 
net objektumokra irányuló kérések teljesítéséhez. Ez biztosít- 
ja a gyors elérést, az alacsony fenntartási költségeket és a 
tárterület hatékony kihasználását. Mindegyik internetobjek- 
tum a tömb egyetlen ISA Server-én található csak meg, így a 
tömbök egyetlen logikai gyorsítótárként működnek. Termé- 
szetesen, a CARP biztosítja a skálázhatóságot is, vagyis ahogy 
egyre több ISA kerül a tömbbe, úgy nő a teljesítmény is. 


Gyorsítótár láncok (hierarchikus gyorsítótárak) 

A lánc az ISA Server-t futtató számítógépek hierarchikus 
kapcsolata. Az ügyfelek kérései felfelé haladnak a gyorsító- 
tár-hierarchiában, egészen addig, amíg meg nem találódik 
(csak magyarosan! :) ) a keresett objektum. Egy fiókirodá- 
ban levő ügyfél kérése például először a fiókiroda ISA Ser- 
ver-éhez megy, majd a területi vállalati központhoz, mie- 
lőtt kijutna az Internetre. 

A gyorsítótár lánc tagja lehet egy ISA Server számítógép, 
vagy akár egy ISA Server tömb is. A láncok kialakítása is 
hatékony mód a kiszolgálók terhelésének elosztására és a 
hibatűrés kialakítására. Secure sockets layer (SSL) láncok 
kialakítása is támogatott. 

Az elosztott gyorsítótárak és a hierarchikus láncok kialakí- 
tásával az ISA Server akár a legnagyobb nagyvállalat igé- 
nyeinek megfelelően is skálázható. A CARP hatékony töm- 
bök kialakítására szolgál, melyek jó teljesítményt, hibatű- 
rést és skálázhatóságot biztosítanak. 






Fiókiroda 
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Riasztások 

Az ISA Server testreszabható rugalmas riasztási szolgáltatá- 
sa segít a hálózat elleni támadások és a rendszeresemények 
megfigyelésében, és azok megfelelő kezelésében. A riasztá- 
si szolgáltatás biztosítja előre definiált cselekvéssorozatok 
elindításának támogatását (automatikus levélküldés a rend- 
szergazdának, szolgáltatások elindítása és megállítása, egye- 
di szkriptek vagy programok futtatása) . A riasztási szolgálta- 
tás eseményelosztóként és -szűrőként működik. Ez felelős az 
események elfogásáért, az adott feltételek teljesülésének el- 
lenőrzéséért és a megfelelő cselekvések végrehajtásáért. 

Az eseményalapú riasztások és a testreszabható cselekvésso- 
rozatok végrehajtásának támogatásával az ISA Server olyan 
rugalmas felügyeleti eszközt biztosít, mely segítséget nyújt 
a biztonságos tűzfal és hálózat fenntartásában. A vállalati 
biztonság egyik fő eleme a támadásokról való értesülés és a 
gyors ellenlépés végrehajtásának képessége. Ez tényleg na- 
gyon fontos. Valljuk be őszintén, hogy ami jól működik, ar- 
ról az ,Egy gonddal kevesebb." felkiáltás kíséretében hajla- 
mosak vagyunk elfelejtkezni. Közben meg lehet, hogy vala- 
ki már két hete vígan , hekkelgeti" a tűzfalunkat. 


Jelentések készítése 

Az ISA Server-ben előre elkészített jelentésminták találhatók, 
melyek nagyban megkönnyítik a biztonsági problémák, és az 
internethasználat elemzését. Bár maga az ISA csak alapvető 
jelentések készítését támogatja, kiterjedt jelentéskezelő API- 
készletet tartalmaz, melynek segítségével külső gyártók jelen- 
téskészítő és -kezelő eszközeit is alkalmazhatjuk. 

A jelentéskészítő mechanizmus ISA Serverenként egy adat- 
bázisba gyűjti a naplókat, majd a jelentés készítésekor ezen 
naplók vizsgált időtartamra vonatkozó bejegyzései egyetlen 
adatbázisba kerülnek, és ennek alapján készül el a jelentés. 
Ez az adatbázis egy adott ISA Server-en helyezkedik el, és 
a jelentések is csak ezen a számítógépen nézhetők meg. 
Természetesen az összegyűjtött adatok alapján rendszeres 
időközönként, és automatikusan összefoglalók készíthetők 
vállalatunk internetfelhasználásáról. 


Előre definiált jelentések 
Az ISA-ban az alábbi előre definiált jelentések találhatók meg: 
"8 összesített jelentések 
a webhasználatról szóló jelentések 

az alkalmazások használatáról szóló jelentések 
"8 forgalmi jelentések és sávszélességkihasználtság jelentések 
"8 biztonsági jelentések 
Hát ennyi lett volna az e havi cikk. Jövő hónapban (istenbi- 
Zony) felépítünk egy tesztrendszert. (Tehát aki tényleg ki akar- 
Ja próbálni a leírtakat, kezdje gyűjteni a PC-ket. Jövő hónapban 
még csak háromra lesz szükség, később négyre. Ja, és az egyik- 
ben legyen három darab hálózati kártya. Szükség lesz rá.) 


a 
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Domain 


JOGI 


vitarendezési 


eljárások 

Korábban már ugyanezeken az oldalakon szóltam a magyar 
domainregisztrációs rendszerről és ott nagy vonalakban ki- 
tértem a hazai vitarendezési eljárásra is. 

Ezúttal azonban a gTLD (Generic Top Level Domain) körében 
az ICANN [1] által meghatározott szabályok szerint folyó, a 
WIPO [2] keretein belül működő sajátos vitarendezési eljá- 
rásokat szeretném ismertetni. 


d v1Po - world Inteltedtval Property Organization - Micrasoít 
Ele Edt Wow Favortes Ivo: tp ) Mddress 








sua: 2: OH Asse Glenn Gr [5: ő 











5 A WIPO-n megtalálhatók a korábbi vitás ügyek... 


A generikus kódok (gTLD) az eddigi használat szerint a .com, 
.net, .org, de mint tudjuk, számos új elfogadása már megtör- 
tént és bevezetése a közeli jövőben várható. E körben a doma- 
inregisztráció szabályait az ICANN állapította meg. Itt nem 
működik semmilyen különösebb előzetes vizsgálat, a , first 
step first served" elve szerint az igénylőnek - ha az adott do- 
main nem foglalt - automatikusan regisztrálják a kért nevet. 
Akinek jogát sérti az adott regisztrálás, nem marad más hátra 
a rosszhiszemű cyber-tér foglalóval szemben, mint valamilyen 
jogorvoslati úton eltiltatni a domain használatától a jogsértőt 
és megszerezni a maga számára a kért domaint. 

A hagyományos bírói út a világ más részein, a Lajtán és az 
Atlanti óceánon túl is éppoly lassan nyújt eredményt, mint 
a Kárpát medencében. Az Internet világa viszont éppen ezt 
az egyet nem tűrheti, hiszen az eleve a minden eddiginél 
gyorsabb információáramlásra épülő rendszerben a bírói 
döntés megszületéséig olyan mérvű jogsértés történhet, 
amelynek jóvátétele már szinte alig lenne lehetséges, és a 
jogosult részéről is érdekmúlás következhet be. Fel kell te- 
hát kínálni egy olyan alternatív utat, amely gyors megol- 
dást nyújthat, még ha ideiglenes jelleggel is - még ha csak 
néhány szempontra helyezzük is a vizsgálódást. 
Valamennyi gTLD regisztrátor elfogadta a hosszú egyezteté- 
sek, nehéz küzdelem eredményeként megszületett egységes 
vitarendezési eljárást (Uniform Domain Name Dispute Policy 
ill. Rules for Uniform Domain Name Dispute Resolution Poli- 
cy). Ez azt jelenti, hogy ha egy adott védjegy jogosultja a 
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rosszhiszemű domainigénylővel szemben az e rendszer ke- 
retében a WIPO mellett felállított testület döntését kéri, a 
döntést a regisztrátor végrehajtja, és ha az a domain átru- 
házását rendeli el, úgy a kérelmezőre átruházza. 

Az eljárás nem választott bíróságot hozott lére. A választott 
bíróság ítélete a törvény erejénél fogva jogerős, végrehajt- 
ható, az állami végrehajtási rendszer útján kikényszeríthe- 
tő. Ellene jogorvoslatnak helye nincs, és csak nagyon szűk 
körben, súlyos eljárási szabálysértés esetén van arra mód, 
hogy az ítéletet hatályon kívül helyeztessék. 


Az adminisztratív panel 
Az ICANN egységes eljárásában a fő szerep az ún. adminiszt- 
ratív panelnek jut, amely a felek választása szerint 1-3 
főből áll. Döntését a regisztrátor végrehajtja, kivéve, ha a 
fél igazolja, hogy a döntés kézhezvételétől számított 10 na- 
pon belül bírósághoz fordult. Itt tehát nem jogerős és álla- 
mi erővel végrehajtható határozat születik, hanem egy 
olyan döntés, amelynek végrehajtását az önkéntes alávetés 
garantálja, és amely után még a rendes vagy választott bí- 
rói út a maga teljes egészében nyitva áll a felek előtt. 
Az adminisztratív panel tagjait egy listáról jelölik ki. Az el- 
járás írásban folyik, nincs személyes meghallgatás, és a ké- 
relem beérkezésétől számított 45 napon belül befejeződik. 
A határidők rendkívül szorosak és betartásukat a döntés ad- 
dául a kérelmezett fél által elkésetten előterjesztett véde- 
kezést már nem veszik figyelembe a döntés során. 
Az eljárás kérelemre indul, amelynek az előírt tartalmi jegyek- 
kel rendelkeznie kell. A kérelemből megállapíthatónak kell 
lennie, hogy a kérelmező jogosult az adott domain névre. 
Az eljárás díja 1000 - 3000 USD közötti összeg, amely a ma- 
gyar szokásokhoz képest meglehetősen magas, de ha az 
egyes domainek piaci értékét, és a döntés gyorsaságát néz- 
zük, akkor megéri megfizetni, és amint ezt a statisztika bi- 
zonyítja sok esetben meg is teszik. Ez különösen abból a 
szempontból érdekes, hogy - a bírósági eljárásokkal szem- 
ben - itt a , vesztes" fél nem köteles megtéríteni utóbb az 
eljárási díjat a kérelmezőnek. Közvetve következtethetünk 
tehát arra, hogy az egyes domainek átruházásáért mekkora 
ellenértéket kérnek a piacon. 

A kérelmező javára szóló döntéshez az alábbi feltételeknek 

kell együttesen fennállniuk: 

"8 a domainnév azonos vagy összetéveszthetőségig hason- 
ló egy áru vagy szolgáltatási védjegyhez, amelynek a 
Kérelmező a jogosultja, és A 

"0 a regisztrált használónak nincs jogcíme vagy jogszerű 
igénye (érdeke) a domain névhez, és 

"8 a domainnevet rosszhiszeműen regisztráltatta és használta 

E felsorolásból láthatjuk, hogy ez az eljárás csak akkor ve- 

hető igénybe, ha kifejezetten védjegyjogot sért a domain- 

regisztráció. Nem járható út tehát ha a versenyjogi szabá- 
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lyok, személyiségi jog, stb. sérelmére alapítja valaki a ké- 
relmét. Ez esetben tehát marad a rendes bírói út. 
Ugyanakkor a védjegyjogosult jogával szemben eredményes 
védekezés lehet, ha a kérelmezett a domainnevet: 

"? már annak nyilvántartásba vétele előtt használta a sa- 

. ját áruja vagy szolgáltatása körében, vagy erre bizo- 
nyíthatóan előkészületeket tett 

"? ha a domainnév megegyezik azzal a névvel amelyen már 
korábban magánszemélyként vagy gazdálkodó illetve 
más szervezetként ismerték (pl. cégként ezen a néven 
bejegyezték) 

"0 a domainnevet nem kereskedelmi jelleggel, rendeltetés- 
szerűen használja, anélkül, hogy célja lenne a védjegy jogo- 
sultjának potenciális vásárlóinak eltérítése, vagy a szóban 
forgó védjegy megkülönböztető jellegének elhalványítása 


A vitás ügyek lezárása 
A döntés a következő változatok egyike lehet: 
"0 az adminisztratív panel megállapítja, hogy a domaint 
rosszhiszeműen regisztrálták, és annak törlését rendeli el 
"8 az adminisztratív panel megállapítja, hogy a domaint 
rosszhiszeműen regisztrálták és annak a kérelmező ja- 
vára történő átruházását rendeli el 
"0 az adminisztratív panel a kérelmet elutasítja 
Külön figyelmet érdemel, hogy az egységes eljárási szabá- 
lyok mit tekintenek a rosszhiszeműség bizonyítékának. Ön- 
magában megállapítható a rosszhiszeműség, ha annak átru- 
házása ellenértékeként akkora összeget kérnek, amely a re- 
gisztrálással ténylegesen felmerülő költségeket meghalad- 
ja. Ugyancsak rosszhiszemű a regisztrálás, ha annak célja az 
volt, hogy a védjegy jogosultját megakadályozza abban, 
hogy a saját védjegyét domain neveként feltüntesse, vagy 
ha a cél a versenytárs üzletének megzavarása volt, vagy ha 
a domainnevet a kérelmezővel való összetéveszthetőség 
céljából a piaci előny megszerzéséhez kívánták használni 
úgy, hogy a honlapon vagy más on-line lapon az azonos- 
ság, összefonódás látszatát keltették. 
Sok esetben megállapítják a rosszhiszeműséget akkor is, ha 
a kérelmező csak azt igazolja, hogy a domain azonos vagy 
az összetéveszthetőségig hasonló az ő védjegyével, és a ké- 
relmezett fél nem terjeszt elő semmilyen védekezést. A bi- 
zonyítás ugyanis a kérelmezett felet terheli. Ugyanakkor is- 
mertek olyan döntések is, amelyeknél egy ügyes védekezés- 
sel el lehetett érni a panasz elutasítását. 
Mindenképpen érdemes egy .com, .org. vagy .net domain 
jogvita kezdeményezése előtt, vagy ha abba kérelmezett- 
ként kerül az ember, hozzáértő ügyvéddel konzultálni. A 
magyar érdekeltségű ügyek közül ismert olyan, ahol az 
ügyes ügyvédi trükk segített megtartani a nyilvánvalóan 
jogsértő domaint. Itt a kérelmező a Casino Monte-Carlo 
volt, amelynek védjegyéhez nagyon hasonló domaint egy 
magyar betéti társaság regisztráltatott. Az eljárás megindí- 
tását követően azonban a domaint átruházta egy másik tár- 
saságra, amelynek tevékenységi körében szerencsejáték- 
szervezés is volt, és amely arra hivatkozott, hogy e cím 
alatti honlapon szerencsejátékot kíván szervezni. Így a 
rosszhiszeműséget nem tartotta megállapíthatónak az eljá- 
ró panel és a kérelmet elutasította. 
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Az eddigi statisztikák szerint egy magyar kérelmező fordult 
a panelhez, a Zwack Unicum Rt., amely a zwackunikum.com 
domain átruházását kérte. A kérelmezett nyilvánvalóan 
rosszhiszemű eljárását az is bizonyította, hogy az említett 
domainnév alatt a Jágermeister - a közismert versenytárs -— 
reklámja volt látható. 

Az ismertetett eljárás tehát a nemzetközi domainpiacon 
működik. Nem terjed ki azonban a ccTLD-k alatt regisztrált 
domainekre, így a .hu alattira sem. Ennek oka nyilvánva- 
lóan abban rejlik, hogy amíg a nemzetközi jogviták eseté- 
ben azok jellemzője a jogok közötti állapot, vagyis az alkal- 
mazandó jogot az ide-oda utaló szabályok alapján kell 
megállapítani, addig az országnevek alatt egyértelműen a 
hazai jog szerint kell a jogvitát eldönteni. Itt viszont a re- 
gisztrátorok felelőssége, az igények jó és rosszhiszeműsége 
más elvárások és más szabályok szerint kerül elbírálásra. 

A jövő nyilván e területen is a közelítés, a harmonizáció 
lesz. Addig azonban be kell érnünk az ahány ház, annyi szo- 
kás megoldással. 


Sértettek és bitorlók 

A [2] címen végzett kutatás érdekes eredményeket hozott 
a tavalyi év összesen 1841 ügyének megoszlásában. Vannak 
ugyanis csaló, domainbitorló országok. A sértettek tizes 
toplistáján (egy kivétellel) természetesen a legfejlettebb 
országokat találjuk (USA, Egyesült Királyság, Franciaország, 
Spanyolország, Németország, Ausztrália, Japán, Svájc és ka- 
kukktojásként: India), addig a bitorlók listáján a negyedik 
helyet Dél-Korea foglalja el, a hatodik Kína. Kis hazánk a 
becsületes népek táborát gyarapítja, mivel míg sértettként 
a 45. helyen áll, a bitorlók listáján már csak ötvenedik. 


Dr. Mayer Erika 
Nádas 8. Mayer Ügyvédi Iroda 
mayer(onadas-mayer.hu 


A cikkben szereplő URL-ek 


[1] http://www.icann.org 
[2] http://www.wipo.org 
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ASP suli 
- Hibakezelés ú 


(V. rész) ns 


Hibátlan szoftver - mint tudjuk - nem létezik. Ez a tétel 
igaz az ASP alkalmazásokra is. Ma az ASP programozás során 
fellépő hibák hatékony kezeléséről és elkerüléséről lesz szó. 


Rendezzük a felszínt 

Az ASP alkalmazásokban fellépő hibák rendszerint kellemes 
hibaüzenet formájában jelennek meg a felhasználónál. Termé- 
szetesen nem feltétlenül egészséges, ha egy-egy ilyen hibaüze- 
net, esetleg kódrészlet nyilvánosságra kerül, ezért megvan a 
módja annak, hogy - miközben mi a hiba kezelését végezzük - 
a felhasználót megkíméljük a kínos részletektől. 

Az IIS alapértelmezése szerint az alábbi ábrán O jellel jelölt 
hibaüzenet-oldal jelentkezik a felhasználónál, ami egyrészt 
praktikus, mert szép és színes, másrészt kellemetlen lehet, hi- 
szen tartalmazza a hiba komplett leírását. Ezt az oldalt egyéb- 
ként a WwinntthelpVisHelptcommon 500-100.asp állítja elő. 





5 Egy hiba három arca. Az O jelű az alapértelmezés, a o 
egy köztes állapot, a 0 végfelhasználóknak szánt változat 


Miközben nyilván nagyon hasznos a részletes hibaüzenet, 
éles környezetben ez nem feltétlenül igény. Az ASP scriptek 
végrehajtása során fellépő hibák esetén a teendőt a virtuá- 
lis könyvtár tulajdonságlapjának Custom Errors oldalán az 
500;100 sorhoz tartozó beállítása határozza meg. Amint az 
az alábbi ábrán is látható 9, alapértelmezésben a fentebb 
említett hibakezelő oldalra adódik a vezérlés. 

















ET er] ver] ve] 


0 Hibakezelési beállítások a webalkalmazásban. Az 0 
beállítás csak akkor érvényesül, ha a 9-et alapértelme- 
zésre (Default) állítjuk 


Ezt a beállítást átirányíthatjuk valami saját magunk által 


készített hibakezelő oldalra (ami mondjuk naplózza is a fel- 
merült hibákat, ilyet fogunk létrehozni később), vagy vá- 
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laszthatjuk az alapértelmezést is (a Default beállítás, illetve 
Set to Default... gomb segítségével). Amikor az 500;100 hi- 
bához nincs beállítva külön hibakezelő fájl, a webalkalma- 
zás beállításai között, az App Debugging oldalon található 
beállítás 6 az irányadó. Ha ezt a beállítást az első lehető- 
ségen hagyjuk (,Send detailed error messages to client"), 
akkor a O példához hasonló hibaüzenetek jelennek meg a 
böngészőkben. Ezek nem kevésbé bőbeszédűek, mint az 
alapértelmezett hibakezelő oldal, viszont jóval rondábbak: 
egyszerűen a kliens arcába vágják a hibát. 

Ha viszont a másik opciót választjuk, megadhatunk egy 
saját hibaüzenetet (ami tartalmazhat HTML elemeket is, ld. 
az ábrán). Végfelhasználói környezetben ez az egyik 
legegyszerűbb és legjobb megoldás, hacsak nem akarunk 
saját hibakezelő oldalt írni. 


Írjunk saját hibakezelő oldalt! 

Ehhez minden támogatást megkapunk az Internet Informa- 
lehetőségét (ezt az előbb már láthattuk), másrészt pedig a 
hiba felismeréséhez, feldolgozásához szükséges információ- 
kat, az ASPError objektum formájában. 

Miután a megfelelő könyvtárban beállítottuk a hibakezelő oldalt 
a sajátunkra, kezdjünk neki a munkának. Mindenekelőtt, ha a 
pufferba már írtak, amikor a hiba bekövetkezett, itt az ideje, 
hogy kiürítsük, és a hibakezelő oldal tiszta lappal indulhasson: 


cz 
If Response.Buffer Then 


Response.Clear 


Azután: a válasz státuszát állítsuk be hibaüzenetre, nehogy 
valaki azt higgye, hogy ez a valódi oldal: 


Response.Status 5 "500 Internal Server Error" 


Majd állítsuk be az oldal tartalmát HTML-re, a lejárati időt 
0-ra (így a gyorsítótárak nem fogják az oldalt letárolni) : 


Response.ContentType - "text/html" 
Response.Expires - 0 


End If 


A következő lépés a hibát leíró ASPError objektum előcsalo- 
gatása, amit a következőképpen tehetünk meg: 


Set objASPError - Server.GetLastError 


Miután az objektum megvan, belekezdhetünk a jellemzők 
lekérdezésébe. Az egyes jellemzők jelentése a következő: 
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"6 .Category: a hiba kategóriája, szöveges jellemző, pl. 
Microsoft VBScript compilation" 

"8 .Number: a hiba kódja, hexadecimálisan megjelenítve 
sokatmondó lehet (rá lehet keresni a tudásbázisban) 

"0 .Description: a hiba leírása, maga a hibaüzenet 

"0- .File: a fájl neve, ahol a hiba keletkezett 

"8 .Line, .Column: a hiba felismerésének sora és oszlopa 
(ez az adat nem mindig áll rendelkezésre, ilyenkor az egyes 
jellemzők értéke -1). Vigyázzunk, a hiba felismerésének 
helye nem feltétlenül egyezik meg a hiba helyével! 

"0 .Source: a hibát okozó sor kódja. Nem mindig áll ren- 
delkezésre 

"8 .ASPCode, .ASPDescription: a hiba ASP hibakódja és 
leírása - viszonylag ritkán kapnak értéket 

Állítsunk össze ezekből az adatokból egy hibaüzenetet, egyenlőre 

egy szöveges változóban, mint ahogy az az errhandler.asp példa- 

fájlban is látható [1]. Azért ne írjuk ki a képernyőre, mert egyál- 

talán nem biztos, hogy a felhasználóra tartozik a hiba leírása, jel- 

lege és főleg a helye. Miután a hibaüzenetet összeállítottuk, el- 

dönthetjük, hogy kiírjuk-e a böngészőbe, vagy egy illendő bocsá- 

natkérő szöveg keretében elintézzük a dolgot a színfalak mögött. 

Én azt a megoldást választottam, hogy a felhasználó láthatja a hi- 

baüzenetet, de csak akkor, ha a böngésző a kiszolgálón fut, azaz 

a kliens és a szerver IP címe megegyezik. Az ellenőrzés pillanatá- 

ban a hibaüzenet szövegét már az sErrorText változó tartalmazza: 


ez 
If Reguest.ServerVariables( "LOCAL ADDR") —— 
Reguest.ServerVariables ( "REMOTE ADDR") Or 
Reguest.ServerVariables("REMOTE ADDR") —— 
"127.0.0.1" Then 

35 
LxHR2 
LIPRE2 

cat Response.Write Server.HTMLEncode(sErrorText) 32 
£/PRE2 

c8 Else 85 
LAPPA hibát naplóztuk. Kérjük, próbálkozzon újra 

néhány perc múlva.£/P5 

c$ End If 35 


Vegyük észre a hibaüzenet kiírásánál használt Server. HTMLEn- 
code() függvényt. Mint mindig, ismeretlen szöveg kiírásánál 
használnunk kell, különben az esetleg (scriptkódban nagy 
eséllyel) előforduló speciális karakterek megzavarhatják a 
HTML kódot - gondoljunk csak néhány ártalmatlan kacsacsőr- 
re, ami scriptkorában még matematikai műveletet jelképezett, 
most pedig félkész HTML elemeknek értelmeznénk őket. 
Következő lépésként a korábban bemutatott módszerrel a hibát 
eltároljuk az Eseménynaplóba: 


Set oshell - Server.CreateObject("WScript.Shell") 
oShell.LogEvent 1, "ASP HIBA!" § vbCRLF § sErrorText 
Set oshell - Nothing 


Végül, biztos, ami biztos, a hibát naplózzuk le egy közön- 
séges szövegfájlba is: 


Set oFSO - Server.Createobject 


4 ("Scripting.FileSystemoObject") 
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Set oFile - oFSO.OpenTextFile 

b ("e:Vasperror.txt", 8, True) 
oFile.Write sErrorText § VDCRLF § VvbCRLF 
oFile.Close 


Set oFSO - Nothing 


Ezzel készen is vagyunk. Felmerülhet (és remélem, van már, 
akiben a kód olvasása során fel is merült), hogy a kód így 
nem teljes: mi történik például akkor, ha a naplófájlt vala- 
milyen okból nem lehet megnyitni (például mert éppen más 
valaki ír bele)? Ilyenkor természetesen hiba keletkezik. 


Amikor a hóhért akasztják 
A hibakezelő rutinban keletkező hiba megoldása klasszikus 
feladat. Ilyenkor a hibakezelő oldal már nyilván nem képes 
a szálakat tovább a kezében tartani, szükség van egy fel- 
sőbb ,hatalom" beavatkozására. Esetünkben ez a felsőbb 
hatalom maga az IIS, aki ilyenkor legjobb tudása szerint a 
felhasználó elé hinti a hibát, valahogy így: 
a OLa] 


1 vaslaagi ri c00-ak-i 5 ga alaagi cegem 
[doc föjreröszzuzmeizn JJ] [doom fősavtoztazzeetterzt me 











Hiba történt. 


Hiba történt. 





dna történt az eldal feldolgozása során. 
Kérpuk látogaszon mesza egy másak alkalommal 





Tie fajezz Grass 





a Hiba a hibakezelőben (a képek alján): ilyenkor az IIS 
hibakezelési beállítása érvényes (ld. az előző oldalon: 0) 


Hibakezelés futás közben 

A hiba nem mindig végzetes: az esetek többségében fel tu- 
dunk készülni arra az esetre, ha valami , baj" történne - a 
lényeg csak a hiba biztonságos felismerése. A scriptnyelvek 
éppen ezért általában beépített hibakezelési elemeket tar- 
talmaznak, amelyeket használva a kisebb hibákat még a na- 
gyobb problémák bekövetkezte előtt kivédhetjük. A futás 
közbeni hibakezelő eszközök közös tulajdonsága, hogy a hi- 
ba kezelése után a program futtatása folytatódik. 

A futás közbeni hibakezelés már eléggé scriptnyelv-specifi- 
kus, cikkünk keretében a két beépített nyelv, a VBScript és 
a JScript elemeivel ismerkedhetünk meg. 

Kezdjük a VBScript-tel: itt a futás közbeni hibakezelést 
mindenekelőtt be kell kapcsolni, ha ezt nem tesszük meg, 
mindenképpen hiba keletkezik. A hibakezelés bekapcsolásá- 
ra a következő parancs használható: 


On Error Resume Next 


Azaz kb. , Hiba esetén folytasd a végrehajtást". Ezután rajtunk 
áll, hogy kijavítjuk-e a hibát, vagy egyáltalán foglalkozunk 
vele. Mindaddig amíg ez a parancs érvényes (márpedig abban 
a procedúrában ahol kiadtuk, valamint az abból hívott procedú- 
rákban, érvényes) , a hiba miatt a VBScript nem fog leállni. Ép- 
pen ezért a fenti parancsot globálisan kiadni nem túl éssze- 
rű, a hibakezelés bekapcsolását korlátozzuk kényes helyekre - 
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oda, ahol fel tudunk készülni a hibák javítására. 

A hiba kezelésére (és felismerésére) az Err objektum hasz- 

nálható, amelynek fontosabb jellemzői a következők: 

8 .Number - a hiba kódja, az Err objektum talán legfon- 
tosabb jellemzője. Értéke 0, ha minden rendben van, 
ettől eltérő, ha hiba történt. 

A .Description - a hiba szöveges leírása 

"B .Source - a hibát ,okozó" objektum azonosítója 

Az előző példát tehát ki kell bővíteni: 


On Error Resume Next 
.. hibát okozó rész 
If Err.Number C5 0 Then 
" Hiba a hibakezelőben.. 
Err.Clear() 
End If 


Miután egy hibát kezeltünk, az Err objektumot vissza kell 
állítani a kezdőértékekre, különben a hibát a következő el- 
lenőrző rutin is elkapná. Az Err.Clear() metódust pontosan 
erre találták ki. Mi is meghívhatjuk (célszerűen a hibakeze- 
lő rutin végén), de a VBScript automatikusan meghívja a 
következő utasítások végrehajtása során: 

B On Error Resume Next 

"0 Exit Sub 

0 Exit Function 

... azaz, a procedúrákból, függvényből történő visszatérés- 
kor, valamint a hibakezelés bekapcsolásakor. 

Ha elegünk volt a kánaánból, a futás közbeni hibák keze- 
lését visszakapcsolhatjuk az 


On Error Goto 0 


paranccsal. Ilyenkor hiba esetén ismét a jól ismert hibake- 
zelési megoldások veszik át az irányítást. 

Az objektumnak van még egy érdekes metódusa, ez pedig az 
Err.Raise(). Ez a függvény arra való, hogy hibát váltsunk ki 
a rendszerben. Az Err.Raise() által generált hibák teljes ér- 
tékűek: próbáljuk ki a raise.asp példaprogram segítségével! 


try...catch...finally 

A JScript hibakezelése másképp működik, inkább hasonlít 
a C nyelvben található try...catch utasításpárra. A szinta- 
xis a következő: 


try ( 
7/ hibát okozó művelet 
9 
catch(hibaobjektum) ( 
/7/ hibakezelés 
, 
finally ( 
// mindenképp lefutó utasítások 


JScriptben tehát minden hibát okozó művelet(-csoport) esetén 
külön fel kell készülnünk az esetleg előforduló hibák kezelésé- 
re, ami azt is jelenti, hogy minden egyes esetben külön meg kell 
írnunk a hibakezelő rutint is. A gyanús sorokat a tryí() blokkba 
kell írni. Ha az utasítások végrehajtása során bármilyen hiba 
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keletkezne, a végrehajtás a catch(j blokkban folytatódik. A catch 
paramétereként megadott változó tartalmazza a hiba leírását, 
egy Error objektumot. Példaképpen lássuk, hogyan kaphatjuk el 
a FilegystemObject által visszaadott hibát (jserror1.asp): 


var oFSO - new ActiveXObject 
4 ("Scripting.FileSystemoObject"); 


try ( 

OFSO.CopyFile("gwegweg.txt", "egwewge.txt"); 
? 
catch(e) ( 

Response.Write("Error: " 4$ e); 


Response.Write("cbr:xError Number: " 4 
G  (e.number § OxFFFF) ); 

Response.Write("cbroPDescription: " 4 
b  e.description); 


, 


A hiba oka nyilvánvaló: az aktuális könyvtárban valószínűleg 
nincsen ,gwegweg.txt" nevű fájl, amit másolhatnánk, ezért hi- 
ba történik. A catch-ben megkapott változó egy Error objektu- 
mot tartalmaz, erről már az első sorban kiírt (object Error] is 
tájékoztat minket. A JScript Error objektumának két jellemző- 
je van: az Error.number a hiba kódját, az Error.description a hi- 
ba leírását tartalmazza. A hibakód előcsalogatásához az 
Error.number által visszaadott számot , dekódolnunk" kell, er- 
re való a példában látott (Error.number 8. OxFFFF) kifejezés. 

A try...catch...finally hármas utolsó tagjának az az értel- 
me, hogy olyan utasításokat is megadhassunk, amelyek le- 
futnak függetlenül attól, hogy a try blokkban történt-e hi- 
ba, vagy sem. Hiszen gondoljunk bele: hiba esetén a try 
blokkból azonnal kiugrunk, az esetleg hátralévő utasítások 
mennek a süllyesztőbe. Ez a helye az erőforrások, például 
adatbáziskapcsolatok felszabadításának, lezárásának. 
JIScriptben is idézhetünk elő hibát: a throw() függvény hívásá- 
val hasonló eredményt érünk el, mint a VBScript-beli .Raise me- 
tódussal. A throw() paramétere a hiba maga, ami lehet egy hi- 
bakód, egy szöveg, vagy egy előzőleg előállított, és megfele- 
lően , kitöltött" Error objektum is (jserror2.asp): 


var oErr 5 new Error(); 
oErr.number z 1234; 
oErr.description z "User Error"; 
try ( 

throw(oErr); 
) 
catch(e) ( 


Ha a catch blokkban, a hiba kezelése során zsákutcába ju- 
tunk, és feladjuk a harcot, a munkát tovább passzolhatjuk az 
eggyel magasabb szinten található hibakezelőnek a throw() 
függvénnyel. Paraméterként adjuk neki a catch()-ben átvett 
változót, valahogy így (jserror3.asp): 


catch(e) ( 
Response.Write("Error: " t e); 
Response.Write("cbroxError Number: " 4 
HW. (e.number § OxFFFF) ); 


Response.Write("cbroDescription: " 4 
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4 e.deseription); 


throw(e); 


A második throw() hívás segítségével a hibát tovább passzol- 
tuk az IIS-nek, küzdjön vele ő. A küzdelem eredménye a 
beállításoknak megfelelő IIS hibaüzenet lesz, mintha csak 
nem is lett volna a try...catch blokk. 


Hibakeresés - debugolás 

A futás közbeni hibák néha váratlanul jönnek, nem kerülnek elő 
egyszerűen, de az is előfordulhat, hogy a fejlesztés során sze- 
retnénk akár soronként szemmel kísérni a kód futását, a válto- 
zók értékét. Régebben ezt legfeljebb úgy tehettük meg, ha te- 
leaggattuk a kódot debug üzenetekkel, a program köpte a funk- 
ciótól független információkat, csak győztük kiválogatni, mi a 
valóság és mi a debug által megjelenített adat. 

Fejlettebb programozási környezetben szinte mindenhol meg- 
található a debugger, mellyel végrehajtás közben ellenőriz- 
hetjük a futási paramétereket, követhetjük a program mene- 
tét, sőt, még bele is avatkozhatunk a történésekbe. A Micro- 
soft Script Debugger minden új Windows része, segítségével 
lehetőségünk van kiszolgálóoldali .asp, böngészőoldali .html, 
valamint parancssorból futtatott scriptek debugolására is, 
függetlenül a használt scriptnyelvtől. 

Vannak persze sokkal fejlettebb eszközök (gondoljunk csak 
a Visual Studio kifejezetten erre a célra fejlesztett komponen- 
sére, a Visual InterDev-re), de ez mindig rendelkezésre áll, 
ráadásul nem kerül külön pénzbe. Fontos, hogy a Script De- 
bugger telepítése után az adott webalkalmazás beállításai 
között engedélyezzük a kiszolgálóoldali hibakeresést. 


App Mappings ] App Options . App Debuggng ] 
Debugging Flage: ] 
F7. Enable ASP server-side scxipt debugging 
T 
TE KAl Sr kétkedés 





1z 


90 A hibakeresés engedélyezése a webalkalmazások beál- 
lításai között 


A Script Debuggert háromféleképpen állíthatjuk munkába. 
Mindenekelőtt, a hibakeresés engedélyezése után az oldal- 
ban történt hiba esetén nem a megszokott hibakezelő olda- 
lak futnak le, hanem a kiszolgálón elindul a Script Debug- 
ger, és a végrehajtás mindaddig nem folytatódik, amíg va- 
laki a dologra áldását nem adja - ezért fontos, hogy éles 
környezetben a hibakeresést mindig tartsuk kikapcsolva. 


XHTHL3 CHEADD-€/ HERD3 
ABODY3 
k: 


Response.Wíte "Hello ASP!" 
s. 

LZBODYI 

S/ETHL2 








a Hiba esetén már indul is a Script Debugger 
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A Script Debugger a hiba felderítésére, és nem a script szerkesz- 
tésére való, ezért senkit se lepjen meg a fejlécben olvasható 
Read only" felirat. A debugger - a script kódját tartalmazó mel- 
lett - három különböző ablakot tartalmaz még. Az egyik a Call 
Stack ami a hívásverem aktuális tartalmát jelzi (gyakorlatilag azt, 
hogy hogyan kerültünk a hibához). A második, talán kicsit hasz- 
nosabb ablak a Command Window, amibe futás közben paran- 
csokat gépelhetünk (például új értéket adhatunk a változóknak, 
meghívhatunk függvényeket, stb.). Ha egy változó vagy függvény 
értékére vagyunk kíváncsiak, a kifejezés elé írjunk egy ?-et (ami 
a klasszikus BASIC-ben egyébként a Print parancs rövidítése volt). 
Ha a hibát JScript-ben keressük, a ? használatára nincs szükség. 
Ha nemcsak hiba esetén, hanem általában is szeretnénk a de- 
buggert használni, két lehetőségünk van: az első, hogy a de- 
bugger indítására szolgáló utasítást helyezünk el a kód belse- 
jében. Ez a parancs VBScript esetén a Stop, JScript kódban 
pedig a debugger; (ld. debug1.asp, debug2.asp). A parancs 
hatására a script végrehajtása felfüggesztődik, elindul a de- 
bugger, és a kurzor a parancs sorára áll. 

A másik lehetőség az, hogy a Script Debugger elindítása után 
a Running Documents ablakban kijelöljük a kívánt scriptet, 
majd ráuszítjuk a Break at Next Statement parancsot. Amikor 
legközelebb a végrehajtás az adott scriptre kerül, elindul a 
debugger és kezdhetjük a munkát. 


-4P Microsoft Internet Explorer e B. mén 
Bú Migosolt Active Server Pages (asp5, 960) ú [z 

€-R Oefaut web Sze sás ásás eled etáászasál li 
8- tesps 

HA) eror.asp 


a éstelpfevememan/500-100. asp 


ET sz Microsoft Script Debugger 





Break At Next Statement 


5 Árgus szemekkel várunk a scriptre 


A Running Documents ablakba azok a scriptek kerülnek be, 

amelyek a böngésző (kliensoldali) illetve az IIS (szerverol- 

dali) motorjába már betöltődtek. Az ASP hibakeresést érte- 

lemszerűen a Microsoft Active Server Pages csomópont alatt 

keressük. Ahhoz, hogy egy script itt megjelenjen, be kell 

tölteni, a hibakeresés módja tehát a következő: 

"0 Internet Explorer-be töltsük be a kívánt oldalt 

0 indítsuk el a Script Debugger-t, keressük meg a scrip- 
tet és adjuk ki a Break parancsot 

"8 a böngészőben hívjuk le újra az oldalt (Refresh) 

A Refresh hatására újra betöltődő .asp scriptet pedig már ké- 

pes elkapni a debugger és - mint az az ábrán is látszik - a 

végrehajtás rögtön a script elején a debugger kezébe kerül. 


Fülöp Miklós 
mick onetacademia.net 


A cikkben található URL-ek: 


[1] http://technet.netacademia.net/feladatok/asp/5 
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Az első részben láthattuk, hogy az ősrégi SMTP szabvány és 
formátum képezi az Internetes levelezés alapját. Ezek a 
szabványok annyira jól sikerültek, hogy - bár jelentős 
mennyiségű bővítmény megjelent már azóta, de - a mai na- 
pig nem szakítottunk az SMTP hagyományaival. Az alapokat 
már megismertük, következhetnek a későbbi fejlesztések. 


Multipurpose Internet Mail Extensions 
Szó esett már arról, hogy a tisztán szöveges levelek küldése 
mellett egyre nagyobb lett az igény az internetes levelezés 
más célú felhasználása iránt is. A UUENCODE/UUDECODE 
ugyan rövid ideig megoldásnak tűnt, de csak arra volt képes, 
hogy az amúgy bájtonként nyolc bites adatot át tudjuk tusz- 
kolni az SMTP hagyományosan 7 bites csatornáján. Ez a fela- 
dat azóta is áll, de megjelentek olyan igények is, amelyek 
kielégítésére a UUENCODE már nem volt képes. Például: 

"0 üzenetek küldése nem US-ASCII kódolással (ékezetes be- 
tűk, ne adj" Isten távol-keleti nyelvek használata — hi- 
szen Internet ott is van) - sőt, esetleg az üzenet kü- 
lönböző részeiben különböző kódtáblák használata 

"8 nem szöveges üzenetek (de legalábbis nem tiszta szöveg, 
hanem RTF, SGML, esetleg HTML) 

0 több részből álló üzenetek (esetleg ugyanaz az üzenet több 
formátumban, amiből mindig csak egyet kell megjeleníteni) 

"8 nem ASCII kódolás használata a fejlécmezőkben (például 
ékezetes betűk az üzenet témájában, a feladó és címzett 
nevében) 

Mindezt úgy kellett megoldani, hogy a - nyilván kódolás utá- 

ni - eredmény egy-az-egyben RFC 822-kompatibilis, azaz 

szigorúan 7 bites, ASCII karakterek, rögzített sorhosszúság 
és más paramétereknek megfelelő legyen. 

Sikerült. Az eredmény a MIME (Multipurpose Internet Mail 

Extensions, azaz kb. többcélú internetes levelezési bővítmé- 

nyek) szabványcsalád, jónéhány RFC-ben megfogalmazva. A 

MIME egyébként , csak" egy jól megtervezett keretrendszer, 

ami azóta is bővül, de a tervezői profizmusára utal, hogy a 

mai napig minden bővítményt bele lehet csomagolni. 


Fejléc-paraméterek 

Az előző részben már bemutattuk az SMTP fejléc felépítését 
(név: érték), a fejléc több sorba tördelésének lehetőségét 
és módját. Egy ,apróság" azonban.nem került sorra, még- 
pedig az, hogy a fejlécérték több paramétert is tartalmaz- 
hat, pontosvesszővel elválasztva, valahogy így: 


X-MyFejlec:fejlecertek; 
paraml-parameterertekl; 


param2-parameterertek2 
A fenti példában tehát az X-MyrFejlec értéke fejlecertek, az így 


kialakuló fejlecertek mező param1 paramétere parameterer- 
tek1, param2 paramétere pedig parameterertek2. A paramé- 
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tereket most külön sorba választottuk el (ezt az RFC 822 sza- 
bályai szerint megtehetjük) , de ez ne zavarjon meg senkit, et- 
től a példa mindhárom sora az X-MyFejlec értékét jelképezi. 


A Content-Type fejléc 

A MIME egyik legelső és legfontosabb jellemzője az üzene- 
tek fejrészében megjelenő Content-Type fejléc. E fejléc ér- 
téke határozza meg, hogy a levél milyen tartalmat hordoz, 
hogyan kell azt feldolgozni. A fejléc értéke mindig egy úgy- 
nevezett MIME típus (MIME type) , valamint a típushoz eset- 
leg hozzátartozó paraméterek. A leggyakoribb MIME típuso- 
kat mi is bemutatjuk, de az IETF által regisztrált típusok az 
RFC 2046-ban találhatók meg. A regisztrációs procedúráról 
az RFC 2048 és RFC 2049 szól. Saját MIME típusokat is de- 
finiálhatunk, ezek az X-akármi névre hallgatnak. A saját tí- 
pusok használata az Interneten nem tilos, csak arról 
kell(ene) gondoskodnunk, hogy a levél feladója és címzett- 
je egyaránt ismerje az adott tartalomtípust. 


A charset paraméter 

A MIME egyik újdonsága, mint tudjuk, a különböző kódtáb- 
ták használata volt. A kódtáblák kialakulásáról, használatuk 
szükségességéről most nem szólnék, akit érdekel, az Inter- 
neten utánanézhet (de érdemes ezügyben beleolvasni a 
tech.net magazin márciusi számában található ASP suli 3. 
cikkbe). A lényeg, hogy a világon szerte használt kódtáblák 
közül nekünk a közép-európai, más néven IS0-8859-2, illet- 
ve a Unicode karakterek kódolására használt UTF-8 a ked- 
ves. Szóba jöhet még a nyugat-európai (IS0-8859-1) is, de 
ebben a karaktertáblában a szép magyar ő és ű betűk he- 
lyett csak a hullámos/kalapos változatot találjuk meg. 

A charset paraméter tehát bárhol jelenik meg, a tartalom kód- 
TÁBLÁJÁRA utal - ez nem keverendő össze a tartalom 7 bitessé 
konvertálását végző kódoló ALGORITMUSOKKAL. 


A Content-Transfer-Encoding fejléc 

A Content-Encoding fejléc a tartalom kódolásának módját 

jelzi. Az eredeti RFC 822 ugyanis - mint tudjuk - a hét bi- 

tes ASCII kódkészleten kívül mást nem nagyon hajlandó át- 
vinni, ezért ha ennél többet szeretnénk, kódolásra kénysze- 
rülünk. Hiába használnánk például közép-európai kódtáb- 
lát, az üzenetet nem írhatjuk meg ,csak úgy", hiszen az 
ékezetes karaktereink jóval a hét bites határ felett vannak. 

Ugyanez a helyzet a bináris adatokkal, képekkel, futtatha- 

tó fájlokkal: ezeket mind-mind kódolnunk kell. Kódoláshoz 

többféle algoritmus is ismert, a Content-Transfer-Encoding 
tehát a következő értékeket veheti fel: 

"B 7bit Az alapértelmezés, az adat kódolás nélkül kerül 
az üzenetbe (ennek feltétele, hogy ne tartalmazzon 127 
feletti karaktereket és a 00-t). Soronként legfel- 
jebb 1000 karaktert küldhetünk. 

"0 8bit- 8 bites, kódolás nélküli átvitel. Ez lenne a tel- 
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jesen kézenfekvő, az SMTP gyökerei miatt azonban az 
Interneten használhatatlan. További korlátozás, hogy 
érvényes a soronkénti 1000 karakteres határ. 
"0 binary - 8 bites, kódolás nélküli átvitel, soronkénti 
karakterhatár nélkül. Az Interneten értelemszerűen 
. nem használható 
guoted-printable - ld. később 
base64 - Id. később 
x-akármi - saját kódolás, a Content-Type-hoz hasonló- 
an csak akkor használható, ha a feladó és a címzett 
egyaránt felismeri. Épp emiatt ez a megoldás széles 
körben nem terjedt el. 


ddG 


A fentiek alapján látható, hogy az alapértelmezett, 

ámde butácska 7 bites kódolás mellett két közismert 

alternatíva létezik: a guoted-printable, és a Base64. 

Bármi is a levél tartalma, MIME típusa, a 7 bitre kó- 

dolás e két módszer egyike lesz! 

"0 bináris adatok (például képek) hatékonyan 
Base64 kódolással változtathatók 7 bitessé 

"0 szöveges jellegű infók tipikusan guoted-printab- 
le kódolást kapnak 


Sokakat megzavar a kódtábla (például IS0-8859-2) , és a kó- 
dolási algoritmus (például Base64) hasonló neve. Most ak- 
kor mi történik? Ha IS0-8859-2 kódolást , alkalmazok", ak- 
kor nem kell a levelet 7 bitesre konvertálni (pl. Base64- 
gyel)? De. A kódtáblák ugyanis nem alakítják 7 bitessé a le- 
velet, sőt!, a Unicode egyenesen bináris bájtsorozattá va- 
rázsolja szövegünket! A kódtáblák a célalkalmazásnak segí- 
tenek az adatok megjelenítésében. 

És tekintsünk úgy a Base64 és guoted-printable algoritmu- 
sokra, melyek bármit hálásan 7 bitessé konvertálnak: Unico- 
de, IS0-8859-2 kódtáblájú szöveg GIF, HTML - egyre megy. 


A guoted-printable kódolás 

A guoted-printable rendszer nem minden karaktert kódol, 
csak azokat, amelyek nem esnek az ASCII karakterek tarto- 
mányába. Az ASCII karakterek kódolatlanul, tisztán kerül- 
nek be az üzenetbe, ezért a szöveg , nagyjából" olvasható. 
Az előző mondat például így fest kódolva: 


Az ASCII karakterek k-F3dolatlanul, tiszt-Eln 
4 kerzsFClnek be az 5 

zpCzenetbe, ezzE9rt a sz-F6veg "nagyj-Elb-F31" 
4 olvashat-F3. 


Ugye ismerős? Talán kivehető, hogy a fenti egysoros (sorvég- 
jelet nem tartalmazó) példából két sor lett. Ez azért van, mert 
a guoted-printable kódolás eredményeképpen keletkező adat 
soronként legfeljebb 76 karaktert tartalmazhat. A sortörést 
egy önmagában álló - jelzi. A kódolás lényege, hogy a nem 
ASCII karaktereket hexadecimális kódjukkal helyezi a szöveg- 
be, ami elé egyenlőségjel kerül. A kis hosszú ó-ból így lett pél- 
dául -F3. Az egyenlőségjelet pedig -3D jelképezi. A NetAcade- 
mia kiszolgálójáról, a [2] címről letölthető egy demonstrációs 
script, ami képes guoted-printable kódolásra és dekódolásra is. 
A kódolás többlet , költsége" függ a valójában kódolt karak- 
terek számától, ezért ez a kódolás tiszta bináris adat ese- 
tén pazarló (szövegben nagyobb eséllyel találunk kódolatla- 
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nul elküldhető karaktereket, ezért ezt a kódolást leginkább 
szöveges jellegű adatokon használják) . 


A Base64 kódolás 

A Base64 kódolás egészen más jellegű. Ilyenkor a kódolandó 
szöveg minden 3 bájtját (3x8-24 bit) négy darab hatbites 
részre bontjuk (4x6-24 bit), majd a kapott négy értékhez ki- 
keressük a hozzá tartozó jelet egy táblázatból (ezt Base64 
ABC-nek hívják). A táblázat 2", azaz 64 elemű, és csak olyan 
jeleket tartalmaz, amelyek egy SMTP levélben szerepelhetnek 
(például ASCII karaktereket, de nincs köztük a fejléceket eset- 
leg megzavaró kettőspont, stb.). Az ,árvíztűrő tükörfúrógép" 
szöveg például Base64 kódolással így fog kinézni: 


4XJ27XpOHT3Z3LILIHT8a/ZyZvpy82fpcA--— 


Az eredeti 22 karakterből 32 lett, hiszen minden három betű- 
ből négy készült. A kerekítések azért szerepet játszanak, de 
összességében el lehet mondani, hogy a Base64 kódolt adat 
hossza 4/3-szorosa az eredeti hossznak (ezért csodálkozunk, 
ha a levelező kiszolgáló 1MB-ra állított korlátja nem engedi át a 
levélhez csatolt 1MB-os word dokumentumot...). Miután itt a 
költség állandó, szöveges jellegű adatok esetén jobb a guoted- 
printable kódolást választani. A [3] címről egy demonstrációs 
Base64 kódoló/dekódoló scriptet tölthet le a Kedves Olvasó. 


Az első MIME példa 

A fenti információk alapján már összeállíthatjuk az első pél- 
dalevelünket. A NodePad tökéletesen alkalmas erre a célra. 
Készítsünk egy .eml kiterjesztésű fájlt (az ilyen fájlokra kat- 
tintva elindul az alapértelmezett levelezőprogramunk és meg- 
jeleníti a levelet). A levélbe (továbbra is a NotePad segítsé- 
gével) írjuk a következőt: 


From: "Felado" csenderfémail.hus 

To: "Cimzett" caddresseegmail.huz 
MIME-Version: 1.0 

Content-Type: text/plain; charset-iso-8859-2 
Content-Transfer-Encoding: base64 

Subject: MIME probalevel 


4XJ27XpOt3LLIHT8a/ZyzZvpy82fpcA-- 


CIMERT] KE zaj 


] Be Edt Wew  Iools Message  Hebp 
9 AV 8 Ax 48. s 
Reply Reply AN Forward Print. Delete Previous 


From: —— Felado 

Date: Tuesday, May 22, 2001 10:17 AM 
Tor mzett 

Subject: MIME proba level 





árvíztűrő tükörfúrógép 








0 Ki hitte volna, hogy valaha Notepaddel írunk MIME 
levelet? 


A fejlécek szerint ez egy tiszta szöveget tartalmazó levél, 


1S50-8859-2 kódtáblában írva, Base64 kódolással. Egy új fej- 
lécről még nem beszéltünk: 
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MIME-Version: 1.0 


Ez a fejléc szerepel minden MIME levél fejrészében, a levele- 
zőprogram innen tudja, hogy a tartalmat a MIME szabályai- 
nak megfelelően kell feldolgoznia. Mielőtt rátérnénk a külön- 
böző tartalomtípusokra, maradjunk még egy kicsit az ékeze- 
teknél: hogyan érjük el, hogy a fejlécekben (feladó, címzett 
neve, levél témája) se kelljen lemondani az ékezetekről? 


Kódtáblák a fejlécekben 

Az SMTP fejlécekben kicsit bonyolultabban kellett megolda- 
ni a kódolást. A kódolási megoldások persze megmaradtak 
(Base64, Ouoted-Printable) , de ki kellett találni egy formá- 
tumot, aminek alapján az olvasó felismerheti, hogy kódolt 
formátummal áll szemben, és ami nem ütközik az SMTP fej- 
lécekre vonatkozó szabályokkal. Arról nem is beszélve, hogy 
most fejlécenként meg kell mondanunk, hogy a következő 
adat milyen kódtáblában, milyen kódolással került bele a 
fejlécbe. (Erről a témáról egyébként az RFC 2047 szól). 
Mindenekelőtt: a kódolandó szöveget legfeljebb 75 karak- 
teres részekre bontjuk, és minden részre külön értelmezzük 
az alábbiakat. A kódolt szövegrészeket azután egymás 
után, sortöréssel elválasztva (a több sorba tördelt fejlécek 
szabályait betartva) írjuk bele az üzenetbe. 

A kódolt szövegrész a következő formátumú, legfeljebb 
75 karakter hosszú: 

"z?" charset "?" encoding "?" encoded-text "?-" 

. . ahol a charset a használt kódtábla típusa (pl. iso-8859-2) , 
az encoding a kódolás azonosítója (b vagy B a Base64, g vagy 
a a guoted-printable jele) , végül az encoded text maga a kó- 
dolt adat. A kódolt szövegben nem szerepelhet kódolatlanul 
a szóköz, tabulátor, vagy sorvégjel. A guoted-printable kódo- 
lásban a szóközt a . (alulvonás) is helyettesítheti. Szilícium- 
völgyi Fű Benő például így néz ki, ha levelet küld: 


5?iso-8859-2?g?SzilsEDciumvsF6lgyi F-FB Ben-F5?- 


A példára pillantva rögtön látszik, hogy a használt kódtábla a 
közép-európai (I1S50-8859-2) , a kódolás guoted-printable (g), va- 
lamint látható, hogy a nevek közötti szóköz alulvonássá változott. 
Ezt a kódolási módszert a címzésekben (feladó, címzett, 
másolat, stb.), valamint a levél témájában használhatjuk. 


Tartalomtípusok 
Mint tudjuk, a Content-Type fejléc tartalma jelzi, hogy az üze- 
net (vagy üzenetrész) milyen tartalmat hordoz magában. A tí- 
pusazonosítók két részből állnak, amelyet / jel választ el egy- 
mástól. A jel előtti rész a főcsoport, a jel utáni az alcsoport azo- 
nosítója. Jelenleg hét főcsoport létezik, az alcsoportokat érte- 
lemszerűen nem érdemes számolni. Most felsoroljuk a leggyak- 
rabban használt tartalomtípusokat, illetve azok leírásait, a tel- 
jes lista szerte az RFC-k között található meg (pl. RFC 2046): 
"B text/plain: egyszerű szöveg 
"0 text/html: HTML tartalom, az egyre elterjedtebb HTML 
alapú levelek azonosítója. A charset paraméter itt is hasz- 
nálható, bár a HTML nyelv önmaga is tartalmaz a kód- 
táblák kezelésére való elemeket. Lásd még: RFC 1866. 
"8 image/gif, image/jpeg, image/bmp: Képek, grafikák. 
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"8 audio/basic, audio/32kadpcm, video/mpeg: Multimé- 
dia audio és videó, ma már inkább HTML levélbe 
ágyazva találhatók meg (bár csatolt fájlként még ta- 
lálkozhatunk ezekkel a típusazonosítókkal is). 

"8 application/msword, application/vnd.ms-excel: Az appli- 

cation főcsoportba tartoznak a különböző alkalmazá- 

sok által használt formátumok, mint a példában emlí- 
tett word, illetve excel. Az , alternatív" formátumok ál- 
talában ebbe a főcsoportba kerülnek. 
application/octet-stream: 8 bites adat 
application/x-pgp-keys, application/x-pgp-signature, 

application/x-pgp-encrypted: a PGP titkosítással ill. di- 

gitális aláírással ellátott üzenet részei (RFC 2015) 

"8 application/x-pkcs7-MIME, application/x-pkcs7-signature, 
application/x-pkcs10: az SMIME titkosítással illetve digitá- 
lis aláírással ellátott üzenet összetevői (RFC 2311) 

"8 message/rfc822: teljes SMTP levél, fejlécekkel, tartalommal 
együtt. Ez a típusazonosító leggyakrabban akkor látható, 
ha a levelünkhöz másik levelet csatoltunk, illetve, ha...: 

"7 message/delivery-status: ez bizony egy kézbesítési üze- 
net azonosítója. Ilyen üzenetet a jólnevelt levelezőkiszol- 
gálók küldenek, amikor valami hiba történik a levél kézbe- 
sítése, továbbítása során (például: címzett nem található) . 
Az üzenet egy, az SMTP fejlécekhez hasonló adathalmaz, a- 
mi a hiba vagy jelenség jellemzőit tartalmazza. A Reporting- 
MTA a hibaüzenetet küldő levelezőkiszolgáló, a Received- 
From-MTA pedig az a kiszolgáló, akitől a fenti a hibát okozó 
üzenetet kapta. Az Arrival-Date az üzenet érkezésének idő- 
pontja. A kiszolgálókra vonatkozó információk után egy üres 
sor, majd a címzettekről szóló rész következik: láthatjuk az 
eredeti, valamint a valós címzettet (Original-Recipient, Fi- 
nal-Recipient), és például az üzenet lényegét, az ese- 
ményt/műveletet (Action: failed). További információk, il- 
letve a fentiek részletes leírása az RFC 1894-ben található. 

"8 message/disposítion-notification: Ez a típusa az olva- 
sásról kért visszajelzésként érkező üzenet informatív ré- 
szének. Formátuma az előzőhöz hasonló, fejléc-jellegű, 
olvasható benne a címzett neve (Final-Recipient), vala- 
mint az is, hogy mi történt az üzenettel (Disposition: 
displayed, dispatched, processed, deleted, denied, failed) , 
valamint, hogy a visszajelzőüzenet automatikusan, vagy 
a címzett előzetes megkérdezésével érkezett (manual-ac- 
tion, automatic-action) , és még néhány más adat, amiről 
az RFC 2298-ban részletesen is bárki olvashat. 

Az utolsó fő típus-csoport pedig a multipart, ami a MIME 

igazi erejét adja. A több részből álló MIME üzenetekről a 

következő számunkban szólunk. 


$d 


Folytatjuk ... 


Fülöp Miklós 
mick Onetacademia.net 





http: lást zet kSE eke 
[3] Base64 kódoló/dekódoló demonstrációs script: 
http://download.netacademia.net/tools/gp.vbs € 
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Bevezetés 

.NET. Visszhangzik a fejünkben ez a három betű, amelyet egy 
évvel korábban még csak top level domain névként ismerhet- 
tünk, most pedig a legváltozatosabb fórumokon, - mind a Mic- 
rosoft, mind a konkurencia részéről - csak erről hallunk. Mi la- 
kik e három betű (4 karakter) mögött? Valóban óriásit alkotott 
a Microsoft, vagy csak leporolta a Windows DNA-t? Mit takar a 
fogalom? Marketingfrázis, vagy valódi tartalommal bíró tech- 
nológia? A cikkben ezekre a kérdésekre keresem a választ. 


Viszlát COM! 

Fejlesztői szemmel nézve talán nem volt még ekkora változás 
a Microsoft alapú fejlesztések történetében, mint aminek 
most vagyunk a szemtanúi és előbb-utóbb aktív alkalmazói. 
Annak idején a COM (akkori nevén OLE) megjelenése forradal- 
mi volt, mert lehetővé tette különböző programnyelvek 
együttműködését olyan komponenseken keresztül, amelyet 
bármely COM-ot támogató nyelvben fel lehetett használni. Ez 
nagy előrelépés volt a modularizált rendszerek fejlesztésé- 
ben, mert így minden részfeladatnál könnyedén ki lehetett 
választani a megfelelő nyelvet a megfelelő feladatra. 

A COM legnagyobb evangelistája Don Box. ő az elmúlt 10 év- 
ben szinte kizárólag a COM oktatásának szentelte az életét. 
Nemrég megjelent egy cikke ,Is COM dead?" címmel (MSDN 
magazin, 2000. decemberi szám). Ha Don Box-tól ilyen írást 
látok COM ügyben, akkor minimum elgondolkodom. Az el- 
múlt évtizedben a COM volt az alapköve Microsoft technoló- 
giáknak, s most az atya megkérdőjelezi a jövőjét? S mit ír 
Box válaszul a címbeli kérdésére? , Az attól függ, hogyan de- 
finiáljuk a COM-ot." Jó válasz, érezzük a lényegét. A COM, 
mint technológia jó volt, de most tovább kell lépni, mert itt 
kopogtat valaki, aki sokkal többet ígér: a Microsoft.NET. 


Szia .NET! 

Az előző fejezetben önkényesen kiemeltem egy pontot, a COM 
kérdését. Ez nem azt jelenti, hogy a .NET egyfajta COM--r, 
vagy akár stílusosan COMt, csak érzékeltetni akartam, hogy a 
.NET nem egyszerű továbbfejlesztése valaminek, hanem a hát- 
tér teljes újragondolása, és az alapoktól történő újraépítése. 
Nem szeretem a forradalmi jelzőt, mert annak van egy vissza- 
lépésre is utaló mellékíze, de ami most a Microsoftnál történt, 
az tényleg szenzációs. Nem forradalom, hanem továbbfejlő- 
dés, evolúció. A Microsoft átgondolta az eddigi technológiáit, 
megnézte, melyek azok, amelyek jó irányba indultak el, és 
melyek azok, amelyeket az évek folyamán addig fejlesztgetett 
tovább, hogy már nincs értelme tovább bonyolítani, inkább 
érdemes teljesen az alapoktól, a menetközben megváltozott 
igényeknek megfelelően a nulláról újra kidolgozni. Így járt 
például az ADO és az ASP technológia. Mindkettőnek csak a 
neve maradt meg (természetesen .NET kiegészítéssel) , mögöt- 
tük azonban valaki teljesen más lakik, mint az elődjük. 

A váltás fő kiváltó oka az internetes világban zajló változások- 
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ban keresendő. Az eddigi egymástól elszigetelt rendszereket 
egymással automatikusan kommunikálni képes rendszerek fog- 
ják felváltani, függetlenül azok operációs rendszerétől vagy 
hardverétől. Ehhez természetesen mindenki által elfogadott 
szabványok kellenek, amelyek első verzióját a World Wide Web 
konzorcium már véglegesen kidolgozta: az adatcserére XML, il- 
letve rá épülve távoli szolgáltatások meghívására a SOAP. 

A .NET-et minden szinten áthatja az XML. Az adatbázisok- 
ból felolvasott rekordokat közvetlenül XML-ként lehet el- 
menteni, XML-t visszaolvasni, formázni, összerakni, transz- 
formálni, visszaírni adatbázisba. A SOAP az alapja a Web 
Szervizeknek, amely a Microsoft víziója az internetes szol- 
gáltatások jövőjéről. Érdemes vele foglalkozni, hamarosan 
minden fejlesztő találkozni fog vele. 

S mi történt a programozási nyelvekkel? Azt nem merem 
mondani, hogy a Visual Basic-kel mi történt, mert annak a 
sorsa még nagyon képlékeny. Elindult azon az úton, ami 
A" programozási nyelvek szűk klikkjébe vezet, ám félúton, 
a Béta1 és a júliusban várható Béta2 között a VB fejlesztők 
nyomására egy kicsit kezdik visszaállítani a , régi" VB szin- 
taktikáját. Nyilvánvaló, hogy erre a már meglevő kódok 
migrációja miatt van szükség, azaz, hogy a VB6-ban megírt 
kódok fussanak VB7.NET alatt is. 

De van egy rossz hírem. A régi és az új Basic csak a szin- 
taktikájában hasonlít egymásra, másban sem. Attól, hogy a 
Microsoft enged a nyomásnak, és a tömbök újra 1-től lesz- 
nek indexelve, mint régen, nos, ez csak egy apróság (per- 
sze sok más is változik) . A lényeg, a háttér alapjaiban meg- 
változott, és a programok nem ilyen apróságok miatt nem 
fognak futni, minthogy félremegy egy index. 

Döntenie kellett a Microsoftnak. Kompatibilitás a régi rend- 
szerekkel, vagy olyan lehetőségek, amelyekről még csak nem 
is álmodtak a VB programozók. Mindenképpen fájdalmas a 
döntés, mert aki már sok munkát belefektetett egy VB6-os 
projektbe, az kompatibilis VB.NET-et akar, aki pedig új szoft- 
vert kezd fejleszteni, az egy olyan nyelvet szeretne, ami 
,Mindent" tud. Úgy tűnik az utóbbi szándék az erősebb. 
Azonban nem egyszerűen arról volt szó, hogy dönteni kel- 
lett a kibővített funkcionalitás és a kompatibilitás között. 
A háttérben ott ül egy kényszerítő erő, az összes .NET-es 
nyelv alapja, amelyet úgy hívnak: 


Common Type System 

És lassan elérkezünk a Microsoft.NET alapjaihoz. Milyen 
adattípusok voltak a Basic-ben? Volt Long, Integer, String 
és még sokan mások, de nem volt például előjel nélküli 
egész szám. Mi volt Cs--ban? Voltak mindenféle egész szá- 
mok, lebegőpontos számok ... és nem volt String. Natívan, 
nyelvi szinten nem volt olyan típus, hogy String. Mit tör- 
tént, ha egy Basic programnak ki kellett olvasni egy C-ben 
deklarált LPCSTR (Long Pointer to Constant String) által hi- 
vatkozott szöveget, mondjuk egy függvényhívás során? Ter- 
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mészetesen ki tudta olvasni, csak tudnia kellett, hogy a 
kapott címen egy nulla bájttal lezárt karaktertömböt talál- 
hat. S mi van, ha egy Delphi-ben deklarált sztringet akart 
kiolvasni? Akkor tudni kellett, hogy a Delphi hogyan tárol- 
ja a sztringeket. Ráadásul a helyzetet csak bonyolítja, 
hogy használunk Unicode karaktereket is. 

Jól látható, hogy a nyelvek között együttműködés egyik fő 
akadálya a különbözőképpen deklarált típusokban keresen- 
dő (emellett még persze a hívási konvenciók és ezer más ap- 
róság is a képbe jön). Ez a szó, a típus kulcsfontosságú 
alapfogalom a .NET-ben. A típus leírja egy objektum táro- 
lásának módját és a típusból létrehozott változókon végre- 
hajtható műveleteket. Ha a Visual Basic, a C--- és a Delphi 
is ugyanolyan módon értelmezné a sztring típust, akkor 
könnyedén érthetnék egymás változóit. 

Mi volna, ha már az elején meghatározhatnánk a legfonto- 
sabb primitív típusokat, és a nyelvek fordítóprogramjainak 
(compiler) kötelező lenne a típus által előírt adatstruktú- 
rákat létrehozni, az objektumokat szabványosan lefoglalni 
és felszabadítani? Ekkor a nyelvek végre megértenék egy- 
mást, és ... elérkeztünk a .NET alapjához, a Common Type 
System-hez (CTS). A CTS-ben leírt típusokat közvetlenül is- 
meri a .NET futtató rendszere, és az összes .NET-es nyelv 
fordítóprogramja. Ennek köszönhetően válnak lehetővé 
olyan együttműködési lehetőségek, amelyekről eddig szó 
sem lehetett. Például egy VB.NET osztály öröklődhet egy 
C4-4-ban vagy Ct-ban leírt komponensben definiált osztály- 
ból! Ezen érdemes egy kicsit elgondolkodni, mert ez már 
nemcsak egyszerű együttműködés a nyelvek között, hanem 
valódi összeépülés, integráció. Köszönjük CTS! 


A Common Language Runtime és a Class Library 

Van közös típusrendszerünk, így a nyelvek közötti integrá- 
ció lehetővé vált. Azonban szükségünk van olyan rendszer- 
re, ami valóban összehozza a különböző nyelveken megírt 
részeket, menedzseli a kódunkat, és szolgáltatásokat nyújt 
a szoftvereinknek. Ez a Common Language Runtime (CLR). 
Az előző fejezetben leírt CTS is a CLR része. 

A választott programnyelvünkben a fordítóprogramok bo- 
csátják a rendelkezésünkre a CLR funkcionalitását. A .NET-es 
fordítóprogramok olyan kódot generálnak, ami közvetlenül 
együttműködik a CLR-el. Az ily módon írt kódot menedzselt 
kódnak hívjuk. Csak a menedzselt kód tudja kihasználni a 
nyelvek közötti együttműködést, valamint a CLR biztonsági, 
nyomkövetési és még számtalan egyéb előnyét. 

A CLR mögött áll egy több ezer(!) osztályból álló kód- 
könyvtár, a Class Library. Az impozáns méretén kívül mi 
ebben a nagyszerű? Egy kicsit gondolkodjunk el a múlton. 
A C44- programozók mögött többféle kódkönyvtár is állt. 
MFC az asztali alkalmazásokhoz, ATL a COM komponensek- 
hez. STL, ha szükségünk volt szabványos algoritmusokra. 
Mi volt a Basic programozók mögött? A Basic Runtime, ami 
teljesen más megközelítésben írta le egy ugyanolyan típu- 
sú alkalmazás szerkezetét. 

Mi történt, ha egy Visual Basic programozót átültettek, 
hogy írjon alkalmazást Cs--ban? Káosz, memory leak, ge- 
neral protection fault és társai. Nem a nyelv szintaktikája 
miatt, hanem azért, mert C---ban sokkal több mindent 
megtehetett, mind Basic-ben (és meg is tett). Emellett a 
nulláról meg kellett tanulnia, hogyan kell létrehozni, pél- 
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dául egy ablakot, mondjuk MFC-ben. 

A nyelv egy eszköz, amellyel a természetes nyelvi problémát le 
tudjuk fordítani valamilyen programozási nyelvre. Olyan nyel- 
vet választok, amihez értek, és amellyel a legtermészeteseb- 
ben le tudom írni a problémát. Ez az elmélet. Ezzel szemben 
általában a nyelvek mögötti kódkönyvtár által nyújtott szol- 
gáltatások döntöttek egy nyelv használata mellett vagy ellen. 
De ennek vége! A Visual Basic.NET programozó pontosan 
ugyanazt a háttérkönyvtárat használhatja a programjaiban, 
mint a CH, Ct, JScript (Perl, Python, Eiffel, Cobol, ...) fej- 
lesztő. A CLR és a Class Library szolgáltatásait nyelvtől füg- 
getlenül ugyanúgy el lehet érni bármely programnyelvből. 
Mindig is voltak kínos kérdések Visual Basic-ben. Többszá- 
lú programozás, registrykezelés, valódi többszálú kompo- 
nensek írása (free vagy neutral threaded). Ezek a funkciók 
mind natív módon benne vannak a CLR-ben, így például 
egy többszálú programot ugyanúgy meg lehet írni Basic- 
ben, mint C----ban, csak a formátum más, a mögötte lege- 
nerálódó kód ugyanaz, ha C4--ben is csak menedzselt kó- 
dot írunk! A C4-4-nak ezután is meglesz az a kiváltsága, 
hogy szabadon azt tegyünk, amit akarunk, azaz kiléphe- 
tünk a menedzselt kód biztonságos keretei közül egy kis 
ámokfutásra. Más kérdés, hogy érdemes-e? 

Azután voltak kínos kérdések még C---ban is (meg persze 
olyanok, amelyek csak Cs--ban voltak kemények, mint a COM 
programozás) . Teljesítnénymutatók figyelése és létrehozása. 
Az NT biztonsági rendszere, ACL, ACE, SID és társai progra- 
mozása. Titkosítás, digitális aláírás készítése. (Hogy megem- 
lítsek hármat a több tucatból.) A Windows 2000 és elődei te- 
le vannak-voltak olyan lehetőségekkel, amelyeket vagy nem 
ismertünk, vagy csak a szabványos API-kon keresztül voltak 
elérhetőek, de akkor meg már megbántuk, hogy megismer- 
tük, mert olyan bonyolultak voltak. Ennek is vége! 

A CLR mögötti osztályhierarchia, a Class Library felfogható 
egyfajta objektumorientált API-nak is. Ebben az a szenzá- 
ciós, hogy az összes nyelvből könnyedén el lehet érni az 
összes szolgáltatást, így nincsenek többé kínos kérdések. 
A Class Library magába olvasztja szinte az összes, eddig 
csak API-n keresztül elérhető szolgáltatást, meg még több 
ezer egyéb feladatot is. Vannak benne klasszikus algorit- 
musok (rendezések, keresések, halmok kezelése, satöbbi), 
valamint rengeteg gyakori feladat kész megoldása (például 
web-es autentikáció, állapotkezelés). Azaz mielőtt nekikez- 
denénk valamilyen funkció implementálásába, érdemes 
szétnézni, nincs-e készen már a Class Library-ben. 


Common Language Specification 

van egy közös alaptípus rendszerre, ez a CTS. Kellett egy 
háttér és kódkönyvtár, ez volt a CLR és a Class Library. 
Azonban mi történik, ha az egyik nyelven megírt kódom- 
ban valami olyan konstrukciót használok, amit nem ismer 
egy másik nyelv, ami szeretne együttműködni vele? Baj, 
nagy baj, megbukna az együttműködés. Hogy ez ne követ- 
kezhessen be, minden .NET nyelvnek támogatnia kell egy 
minimális funkcióhalmazt, de ezen felül még tartalmazhat- 
nak plusz szolgáltatásokat is. Ezt a minimális funkcionali- 
tást írja le a Common Language Specification. 

Ebben a , minimális" halmazban benne vannak olyan fogal- 
mak, mint metódusok felüldefiniálása, öröklődés, vagy az 
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események natív támogatása. Nem csoda, hogy a Visual Ba- 
sic-et ki kellett gyúrni, hisz mit értünk volna egy olyan kö- 
zös nevezővel, mint ami a Visual Basic 6 volt? 

A CTS-ben sokkal több lehetőség van, mint amit a CLS 
megenged. Így abban az esetben, ha a nyelvek közötti 
együttműködés másodlagos szempont, ki lehet használni, 
ha valamelyik nyelv több mindent implementál a CTS-ből, 
mint a másik. És itt jön be az elv, miszerint egyenlők kö- 
zött mindig vannak még egyenlőbbek is. Ha a CTS szinte 
teljes tárházát ki akarjuk használni, akkor használjuk a Ct 
(ejtsd: szí sárp) nyelvet. A legteljesebb módon ezen a nyel- 
ven keresztül lehet hozzáférni a CLR szolgáltatásaihoz. 


A közös nyelv 

Valami trükk kell, hogy legyen a háttérben, hogy annyira kü- 
lönböző nyelvek olyan jól szót értenek egymással. A COM 
technológiában a közös nyelv a gépi kód volt. Bármilyen 
programozási nyelven is írtunk egy COM komponenst, a vé- 
gén x86-os gépi kódra fordult le. Ez szükséges feltétel volt a 
nyelvek közötti együttműködéshez. Ez a bináris kódmegosz- 
tás azonban egy platformra szögezte a komponens használ- 
hatóságát. A .NET stratégia alapköve az információk elérése 
bármilyen eszközről. Első körben mindenkinek a PC jut eszé- 
be, azonban az nem megy velünk mindenhová. Vannak más 
eszközök is, hogy a legkézenfekvőbbet említsem: a mobilte- 
lefonok, amelyek egyre okosabbak, és egyre több információt 
tudnak elénk varázsolni olyan helyeken is, ahol a PC-knek 
nincs létjogosultsága. Milyen processzor van az ilyen kézi ké- 
szülékekben, mint a telefonban, vagy a hand-held PC-kben? 
Milyen nyelven programozzák őket? Ki tudja... 

És mi van, ha azt mondom, hogy az Önök által írt, például Vi- 
sual Basic kód futni fog egy mobiltelefonon? Gondolom, kör- 
beröhögnek. Persze, ha hoznak egy száz form-ból álló progra- 
mot, akkor én is elmosolyodom. Vannak dolgok, amelyek ter- 
mészetüknél fogva csak egyféle típusú gépen fognak futni. 
És mi van, ha azt mondom, hogy az Önök által írt 500 form- 
ból álló VB program futni fog Linux-on, anélkül, hogy Önök- 
nek ehhez bármi erőfeszítést kellene tenni? Nos, akkor le- 
het, hogy már érdekesnek találják, amiről beszélek. 

A Microsoft az információ mindenhol, mindenkor mottót 
komolyan gondolja. A .NET környezet által előállított fut- 
tatható kód ugyanis nincs hozzászögezve egy platformhoz 
sem, futhat bármi olyan eszközön, ami képes ellátni azokat 
a funkciókat, amelyeket a program elvár tőle, minden mó- 
dosítás nélkül. Hogyan tudja ezt megtenni? 

A titok nyitja az Intermediate Language-ben van. Amikor 
egy fordítóprogram lefordítja mondjuk a Ctt kódunkat, akkor 
- ellentétben az eddigi compiler-ekkel - nem gépi kódra, 
hanem egy közbenső nyelvre, az Intermediate Language-re 
(IL) fordít. Magyarán, ha például Windows 2000 alatt lefor- 
dítunk egy hello.cs programot, akkor a hello.exe nem egy 
x86-os bináris kód lesz, hanem egy közbenső kód, IL. 

Mi történik, ha elindítunk egy ilyen exe-t? A .NET frame- 
work, azon belül a CLR Virtual Execution System betölti a 
közbenső kódot, és a szükséges függvényeket, objektumokat 
lefordítja az adott platform gépi nyelvére. Ezt az igény sze- 
rinti, futásidő alatti fordítást Just in Time compilation-nek 
hívják. A jitter (így becézik a JIT compiler-t) nem fordítja le 
egyszerre az egész programot, csak a hivatkozott részeket, 
így gyorsabban indulnak el az alkalmazások. Látszólag ez 
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nagy teljesítményveszteség a bárhol futtatható kódért cse- 
rébe. Azonban tudnunk kell, hogy az IL egy elég alacsony- 
szintű kód, amelyet gyorsan át lehet fordítani gépi nyelvre. 
A futtatás módját (valamivel részletesebben, mint ahogyan 
leírtam) az alábbi ábrán lehet közelebbről szemügyre venni. 
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Kétféle fordítót is lehet írni. Az egyik - figyelembe véve az 
aktuális futásidejű körülményeket - optimalizál, például ész- 
reveszi a processzorcsaládot, az aktuális memóriafelhaszná- 
lást, satöbbi. Így akár az egyik gépen PIII-as processzorra, 
más gépen csak Pentium utasításokat használva generál kó- 
dot. Egy ilyen fordító kifejlesztése elég sok időt igényel, 
ezért nyilván csak olyan eszközökre éri meg megírni, ame- 
lyek várhatóan elég tartósak lesznek, például a PC-k. 

Ezzel szemben egy hűtőgép böngészőjét futtató processzor- 
ra nem biztos, hogy megéri fél évig fordítót fejleszteni, 
mert addigra már úgyis másik processzor lesz benne, elad- 
ják a gyárat, vagy leállnak a típus gyártásával. Az ilyen il- 
lékony platformokra inkább írnak egy egyszerű fordítót, ami 
szinte makrószerűen legenerálja az IL utasítások aktuális 
gépi párját. Egy ilyen fordító egy hét alatt megvan, így 
semmi akadálya annak, hogy a mosógépünkön is fusson a 
szuper képernyővédőnk, csak legyen rá .NET framework. :) 
Az IL kódot elég jól követhetően lehet olvasni, ebben segít az 
IL Disassembler nevű program, ami a .NET Framework SDK része. 
A szemléletesség kedvéért álljon itt egy egyszerű VB.NET 
program, és annak a lefordított IL változta, ahogy az IL Di- 
sassembler mutatja: 


Sub Main() 
Dim i As Integer 
Dim a As Integer -— 20 
For i — 1 To 10 
aza-2 
Next 


Console.WriteLine(a) 
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End Sub 

.method public static void Main() il managed 
( 

// Code size 28 (Oxlc) 
.maxstack 2 
.:1locals init ((0] int32 a, 

[1] int32 i) 

IL 0000: nop 


"IL 0001: Idc.i4.s 20 
IL 0003: stloc.0 

IL 0004: Idc.i4.1 

IL 0005: stloc.1 

IL 0006: I1dloc.0 

IL 0007: Idc.i4.2 

IL 0008: sub.ovf 

IL 0009: stloc.0 


IL 000a: nop 


IL 000b: 1dloc.1 
IL 000€: Idc.i4.1 

IL 0004: add.ovf 

IL 000€e: stloc.1 

IL 000£: Ildloc.1 

IL 0010: Idc.i4.s 10 

IL 0012: ble.s IL 0006 
IL 0014: ldloc.0 

IL 0015: call void 


[mscorlibjSystem.Console: :WriteLine(int32) 
IL 001a: nop 
IL 001b: ret 

) // end of method Modulel::Main 


Jól felismerhetőek az értékadások, illetve a 12-es pozíción 
a for ciklus végén a feltételes visszaugrás a ciklus elejére. 
Ugyanezt a programot megírtam Ct-ban is. A lefordított IL 
kód szinte ugyanaz volt. Nem véletlenül írtam, hogy bár a 
VB kívülről majdnem ugyanaz maradt, belül felnőtt olyan- 
ná, mint a többi programnyelv. 


Csak egyet nem értek. Mit keres az a nop, a ciklus 
közepén (is)? A Ctt IL kódjában nincs benne egy da- 
rab sem. Esélykiegyenlítés? :) 


Nem. A VB fordító csak akkor helyezi el a NOP-okat a kódba, 
ha debug verziót fordítunk. Ez a nyomkövetés közbeni kód 
módosítást teszi lehetővé. 


Metadata, az összekötő kapocs 

Ha .NET, akkor metadata, metadata és metadata. Mit takar 
ez a fogalom, és miért olyan fontos számunkra? 

Egy kicsit nézzünk megint a múltba. Kapunk egy COM kom- 
ponenst, például egy .DLL-ben. Az a feladatunk, hogy do- 
kumentáció nélkül mondjuk meg róla, hogy milyen osztá- 
lyok vannak benne, azok milyen interfészeket implementál- 
nak, milyen metódusaik, tulajdonságaik vannak, a metódu- 
sok visszatérési típusát és paramétereit. Vagy milyen thre- 
ading modellű a komponens? És mondjuk ezt futásidőben, 
VB-ből. Menni fog? Nagyon nehezen, de igen. De van egy 
feltétele: vagy a DLL-hez kell kapjunk egy Type Library-t, 
vagy a DLL-be bele kell, hogy legyen fordítva a TL. Emellett 
nem árt, ha a registry-t is tudjuk olvasni, mert a threading 
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modell ott van leírva. Sőt, ha a kapott komponens be van 
regisztrálva MTS vagy COM-- alá, akkor még azokat a beálli- 
tásokat is le kell kérdezzük, a system catalog-ból. 
Mondhatná valaki, hogy a Visual Studio Object Browser 
megmutatja az összes információt, amire kíváncsi vagyok. 
Hogyne, de honnan is tudja? Az is pontosan arról a három 
helyről szedi össze az információit, amit az előbb leírtam. 
Mindhárom információforrás a COM komponens valamilyen 
jellemzőjét írta le, hogy ezáltal használható legyen a hívó 
számára. Ezek az információk nem csak kényelmi szolgálta- 
tást nyújtanak a Visual Studio felhasználóinak. A Type Libra- 
ry írja le a belépési pontokat (vptr) az osztályok metódusai- 
hoz is. A TL-ban található információk nélkül lehetetlen 
olyan programot írni, ami hatékonyan meg tud hívni egy 
komponens egy metódusát (az IDispath-et végre felejtsük 
el). Azaz eddig is volt leíróinformáció az újrahasznosítható 
komponensekről, csak több helyről kellett összeszednünk. 
Az ilyen jellegű leíró információkat metaadatnak hívjuk. A 
.NET-ben a metaadatok sokkal részletesebb leírást adnak a 
komponensekről, mint a COM-ban. Ez szükséges feltétel 
volt a nyelvek integrációjához. Egy komponens szerkezetét 
a-tól z-ig fel lehet térképezni a System.Reflection osztá- 
lyokon keresztül. Milyen előnyök származnak ebből? 

Mivel a komponensek a teljes leírásukat magukkal viszik, 
nem kell regisztrálni őket! Ez nagyon nagy előrelépés, hisz 
így egy alkalmazás telepítése fájlok másolását jelenti. 


Semmi regsvr32.exe! 


A hivatkozások feloldása futásidőben történik, így a metó- 
dusok hívása előtt biztonsági ellenőrzéseket tud beiktatni 
a CLR (lásd korábbi ábra). Serialization, Remoting. A .NET 
gerincei, mind a metaadatoknak köszönhetően működnek. 
És ami a következő pár évben még nagyon fontos lesz: a 
meglévő COM komponenseinket nem kell kidobnunk, mert a 
háttérben a metadata szolgáltatások segítségével könnye- 
dén meghívhatjuk a COM komponenseket a .NET-es program- 
jainkból. Van egy TlbImp.exe nevű kis programocska, amely- 
nek segítségével a COM komponensek Type Library-jét át- 
konvertálhatjuk .NET metadatává. Ettől kezdve a COM kom- 
ponensünk funkcionalitását éppúgy elérhetjük, mintha az 
egy managed .NET assembly (durván komponens) lenne. 
Azaz a Microsoft nem vágta el az utat a COM felé, sőt ki- 
fejezetten könnyű az együttműködés mindkét irányba. Ez a 
már meglevő hatalmas COM komponenskészlet miatt alap- 
vető szempont volt a .NET tervezésekor. 


Zárszó 

Fejlesztői szemmel átnéztük a .NET stratégia alapköveit. A 
.NET-ről nem 4, de 4000 oldalt is meg lehet tölteni, mégsem 
jutnánk a végére. Ami viszont világosan látszik, hogy döbbene- 
tesen új szelek fújnak a fejlesztésben, amiről kár lenne lema- 
radni. És bár még csak Beta1-es korszakában van a .NET, már 
érdemes vele foglalkozni, mert ősszel már itt is van a végleges 
fejlesztőeszköz és kódkönyvtár. Izgalmas, új korszak kezdődik! 


Soczó Zsolt 
MCSE, MCSD, MCDBA 
Zsolt.Soczo(onetacademia.net 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 06. 





38 


39 


j. 


Ügyfél 
(böngésző) 


DEVELOPER 





Bevezetés 

Az előző számban átnéztük az XML technológia előnyeit a 
webfejlesztésben. Megismertük, hogy mekkora lehetőség 
van az XSL-ben az XML adataink formázásában. A mostani 
részben megnézzük, hogy az előző részekben lefektetett el- 
méletet hogyan tudjuk átültetni a gyakorlatba, XML adat- 
szigetek, XSLT és DOM felhasználásával. 


XML adatszigetek 

Milyen tartalmat küldjön a webkiszolgáló a böngészőnek? 

A HTML formátum nagyon jó a felhasználói felület leírására, 
az adatok megjelenítésére, sőt, scripteket is bele lehet ágyaz- 
ni, de elfedi az adataink jelentését, így ügyféloldalon nagyon 
nehézzé válik azok további kezelése, például, ha helyben ren- 
dezni akarunk. Az XML remek az adataink szállítására, de egy 
weboldalban kellenek scriptek és felhasználói felület is. 


1 Hrultap 


— EE 


2 XML 


ei 


3 HTML-XML 


ES 


5 Adatforgalom a webkiszolgáló és az ügyfélprogram 
között 


Webkiszolgáló 


Valahogyan ötvözni kellene a két technológia előnyeit. Ha 
valamilyen egyszerű, de könnyen kezelhető módon egyszer- 
re tudnánk XML és HTML adatokat is küldeni a böngésző- 
nek, akkor könnyen, gazdag felhasználói felülettel kombi- 
nálva tudnánk az adatokat ügyféloldalon manipulálni. 
Megérkeztünk az XML szigetekhez! 

Internet Explorer 5-től kezdődően megjelent egy cxml: nevű 
HTML elem, amely segítségével XML adatokat ágyazhatunk be 
HTML lapba. A formátuma nagyon egyszerű, a kívánt XML do- 
kumentumot az cxml: c/xmb tagok közé kell rakni, egy azo- 
nosítót adva az szigetnek, hogy script-ből el tudjuk érni: 


chtml5 

chead2 

ctitlesXML tanfolyamokc/titles 

€/head5 

Lbody2 

cxml id-"dsoCourses"5 

cX?xml version-"1.0" encoding-"ISO8859-2"?5 
£courses5 

dXcourses 

£code51905c/code5 

ctitlesBuilding XML-Based Web Applicationsc/titles 
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(III. rész) 


€trainer name-z"Soczó Zsolt"5 

Lemail: 
zsolt.soczognetacademia.net 

c/email: 

£/trainer5 

£/coursez 

Scourse2 

£code51913c/codes 

ctitlesExchanging and transforming data using XML 

and XSLTS/titles 

€trainer name-"Soczó Zsolt": 
Lemail: 

zsolt.soczognetacademia.NET 

€/email: 

€/trainer5 

£/courses 

£/coursesz 

€/xmi5s 

£/body2 

£/html: 


Mit látunk az adatokból, ha ezt a HTML lapot (tanf1.html) 
[1] megnézzük a böngészőben? Semmit. A böngésző magá- 
tól nem jeleníti meg az xml sziget tartalmát, az a mi dol- 
gunk. Azonban hathatós segítséget kaphatunk tőle. Kétfé- 
le módon jeleníthetjük meg a sziget adatait: vagy automa- 
tikusan az adatkötés (data binding) felhasználásával, vagy 
kézzel, scriptből. Nézzük meg őket közelebbről! 


Adatkötés (Data Binding) 

Az Internet Explorer automatikusan képes megjeleníteni az 
xml sziget adatait különböző HTML elemekben, nekünk csak 
jelezni kell, hogy mi az adatok forrása. Ez egyrészt a szige- 
tünk megjelölését jelenti, a szigetnek adott id alapján, illet- 
ve ezen belül meg kell adnunk annak az xml elemnek a ne- 
vét, amelyet meg akarunk jeleníteni. Az alább látható HTML 
kódot kell csak becsempészni a fenti dokumentum törzsébe, 
és máris megjelenítettük a tanfolyamok kódját és címét: 


Tanfolyamkód: Cspan datasrc-" ffidsocCourses" 
datafld-"code" 5€/span:cbr/5 
Tanfolyam címe: Cspan datasrc-" tidsoCourses" 


datafld-"title" 5€/spans 


A böngészőben ez így néz ki: 





AXML tanfolyamok - Microsoft Internet Explorer 


] Fie Edt Wew  Favorites Iools Help 


Tanfolyamkód: 1905 
Tanfolyam címe: Building XML-Based Web Applications 


TT TT [gy computer kh 





(2) Done 
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Nem minden HTML elem köthető adatforráshoz, csak né- 
hány. A tipikusak a div, span, label, frame, img, ha nem 
szerkeszthető módon kellenek az adatok, illetve szinte az 
összes input mező (textbox, checkbox, satöbbi). 

Az előbbi példánk azért több sebből is vérzett. Egyrészt két 
tanfolyamot is meg kellett volna jeleníteni, amihez vala- 
milyen módon annyiszor meg kellene ismételni a span- 
eket, ahány course elem van a szigetben. Mit tehetünk? 
Vagy ,kézzelr, scriptből ismételjük meg a span-eket a 
szükséges darabszámmal, vagy megnézzük, van-e lehetősé- 
günk ismétlődő adatok megjelenítésére. 

Természetesen van. A jó öreg HTML table elemet kiegészí- 
tették az adatkötés képességével. S nem is akármilyennel! 
Az ő feladata az adatforrásban ismétlődő információk meg- 
jelenítése táblázatos formában. Ekkor az adatforrást csak a 
table elemnek kell megadni, a benne levő, megjelenítést 
végző elemeknél már csak a megfelelő mezőt kell jelezni. 
A változatosság kedvéért most a tanfolyam nevét egy in- 
put text mezőhöz csatoltam: 


ctable datasrc-" tdsoCourses" 
Scthead: 


border-z"1"5 


€tr2 

ctd align-"center":Tanfolyamkódc/td: 
£td aligns"center"5:Tanfolyam címec/td2 
e/tr2 

€/thead5 

ctbody2 

ctr5 

cxtd:cspan datafld-"code" 5€/span2c/td: 
Ztdocinput datafld-"title" sizez"60"5c/input2c/td: 
£/tr5 

£/tbody2 

£/tables 






Axmi tanfolyamok - Micrósoft Internet Éxplorer 
[Le Ed Wew  Favortes Io Hep 





















(Tanfolyamkód ( Tanfolyam címe 

[1905 

[113 (B:enaing and vanstormina deta using XML end XSLT 
[Ej Done NE "TT TI mcomoner ek 








Figyeljük meg, hogy a táblázat csak a tbody-ban található 
részt ismétli meg, így tudunk fejlécet adni neki. 

Mi a helyzet azokkal az adatokkal, amelyek a hierarchia mé- 
lyebb szintjén laknak? Ott van mindjárt a ctrainers szekció. 
Közvetlenül nem írhatom be egy harmadik elembe azt, hogy 
datafld-"trainer/email", mert az adatforrást nem lehet 
XPath kifejezésekkel lekérdezni (legalábbis ebben a mezőben 
nem). Azért nem, mert az adatsziget mögött álló adatforrá- 
sobjektum (Data Source Object, DSO) nemcsak XML, hanem 
egyéb adatokat is tud kezelni (szövegfájl, Remote Data Ser- 
vices, ...), és azoknak pedig gőzük sincs az XPath-ról. 
Ennek ellenére a DSO lehetőséget nyújt hierarchikus adatok 
megjelenítésére is. Ehhez egymásba ágyazott táblázatokat 
kell használnunk. A külső megjeleníti a gyökér alatti szint 
adatait, mint az előbb is. Ezen belül definiálhatunk további 
táblázatokat, amelyeknek megadjuk ugyanazt az adatforrást 
mint a szülőtáblázatnak, de megadunk egy mezőt is, azt a 
mezőt (illetve XML-ben azt az elemet), ahol le akarunk fúrni 
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egy szinttel lejjebb. Ezután a táblázatban a már látott módon 

megjelenítjük a megfelelő gyermekelemet. Jelenítsük meg a 

trainer elem gyerekeit, azaz a name és az email értékét! 
Stable datasrc-"dsoCourses" borderz"1"5 

cthead: 

Str 

ctd align-"center":Tanfolyamkódc/td: 

ctd aligns"center""Tanfolyam címec/td: 

StdsxElőadóc/td: 

£/tr2 

£/thead2 

ctbody2 

£tr2 

£tdocspan datafld-"code" 5€/span2c/td2 

ctdocinput datafld-"title" sizez"60"5€/inputoc/td: 


ta. 
€1-- Itt van a beágyazott tábla --2 
€table datasrc-"$dsoCourses"  datafld-"trainer" 


border-"1"5 

£troctdocdiv datafld-"name"5c/divo:c/td: 
ctdoscdiv datafld-"email"5c/div5Cc/td:c/tr5 
£/table: 

€/tdoc/tr: 

£/tbody2 

€/tables 








Előadó 





[dudding X84L-Based Web Applicabonr 


Soczó Zsolt) zzoksoczoffjnetacademianet 





1 
zok toczoffjnetacademia NET f/ 


] a 


h913 


Exchanging and vanstorming dala using 304L and XBLT fee Zsolt 


[ej pere ESZTET 3 zi IETZEZÁK AE SZNZEESESE [ES EZEN vana 





Az XML DSO az XML dokumentumból az elemek attribútu- 
mait és az elemek értékét síkba kiterítve szolgáltatja, így 
a mind a name attribútumot, mind az email elem értéket 
közvetlenül elérhetjük a nevükre hivatkozva. Ha ütközés 
volna egy attribútum neve és elem neve között, akkor fel- 
kiáltójelet kell írni az elem neve elé. 


Interaktivitás, ember! 

Tegyük fel, hogy sok adat van az XML szigetünkben, amelye- 
ket szeretnénk megszűrni. A hagyományos modellben ilyen- 
kor a szűrési feltételt elküldenénk a webkiszolgálónak, az el- 
végezné a szűrést, és az eredményt visszaküldenénk az XML 
szigetben. Természetesen mi olyan megoldást szeretnénk, 
hogy a szerver háborgatása nélkül, a böngészőben tudjunk 
egyszerűbb szűréseket vagy sorbarendezést megejteni. Ekkor 
kell a fejlettebb lehetőségekhez, az XPath és az XSLT vívmá- 
nyaihoz fordulnunk, vagy használhatjuk az XML DOM-ot is. 
Mindkét megoldást megmutatom, mert tanulságos. 

Tegyük fel, hogy a feladat az, hogy lehessen szűrni a tan- 
folyamok nevére. Ehhez fel kell rakjunk egy szövegbeviteli 
mezőt a szűrési feltételhez, és egy gombot, a keresés meg- 
kezdéséhez. A gomb megnyomására ki kell éleznünk egy 
függvény végrehajtását az OnClick eseményre. Itt lesz a 
szűrést végző kódunk: 
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script language-"JScript"5 
£1-— 
function SearchCourse(strCourseFilter) 
1 
//Itt lesz a kereső kód. 
, a 
2 
£/script2 
ginput id-"txtCourseFilter" /5 
Sinput type-"button" value-"Szimat!" 
onclick-"SearchCourse(document.all 


["txtCourseFilter"].value);" /2 


Keresés DOM-mal 

Lássuk hát a feladat megoldását, az XML DOM és XPath fel- 
használásával! 

Az ötlet az, hogy készítünk egy másolatot az eredeti XML 
szigetről, amely az összes adatot tartalmazza. A másolatot 
egy másik XML szigetbe rakjuk, az oldal letöltődése után. 
Amikor a gomb megnyomására keresést kérnek, akkor az 
eredeti XML szigetben található dokumentumból kitörlünk 
minden elemet a courses elem alatt. Ezután végigmegyünk 
a másolat szigetben található course elemeken, és kivá- 
lasztjuk közülük azokat, amelyekre teljesül a feltétel. Eze- 
ket beillesztjük a fő XML szigetünk mögött álló dokumen- 
tumba, és már kész is a szűrés. Ez nagyon favágó módszer, 
de legalább megnézzük, mire képes a DOM. 

Az XML Document Object Model az a programozási absztrakció, 
amely segítségével az XML dokumentumot objektumként, 
programozott módon kezelhetjük. A DOM felolvassa az XML 
forrást, és az elemekből, attribútumokból felépít egy fát, ame- 
lyet programból bejárhatunk, módosíthatunk, és a végered- 
ményt visszamenthetjük az XML dokumentumba. A DOM nem 
Microsoft találmány, a Word Wide Web konzorcium alkotta meg 
és kezeli, a Microsoft XML Parser (MSXML) ennek egy imple- 
mentációja. Természetesen minden gyártó, így a Microsoft is 
kiegészíti egy-két saját funkcióval az általa megvalósított 
DOM-ot, vagy teljesítmény vagy kényelmi okokból. A kiegészí- 
tések is korrektül le vannak dokumentálva az MSDN-ben. 

Az Internet Explorer 5-tel az MSXML 2.0 jött (1998-ban) , amely 
még az akkori w3c javaslatokra épült. Akkor még nem volt XSLT 
csak XSL, nem volt XPath csak XML Patterns. Azóta eltelt három 
év, és most az MSXML parser 3.0 az aktuális, éles környezetben 
is használható verzió. Ezt feltelepítve az Internet Explorer 5 is 
ennek a funkcionalitását fogja bírni, így lesz XSLT és XPath tá- 
mogatásunk. A példákban ezekre fogok építeni. 

Csapjunk bele! Az XML sziget mögötti XML dokumentumot 
elérhetjük a sziget XMLDocument tulajdonságán keresztül: 


var objCourses - dsoCourses.XMLDocument; 


Ekkor visszakapunk egy referenciát az egész XML dokumentumot 
reprezentáló DOMDocument objektumra. Ez magába foglal min- 
dent a forrásdokumentumból, az XML bevezetőtől az utolsó meg- 
jegyzésig. A lap betöltődése után készítsünk ebből egy másolatot: 


cbody onload-"CopyXMLToOriginal();"2 


Xxml id-"dsoOriginal"5c€/xml: 
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//gKészítünk egy másolatot az eredeti 
//dokumentumból, így a szűréseket 
//ebből kiindulva tudjuk elvégezni. 
function CopyXMLToOriginal() 


( 
dsoOriginal.XMLDOocument.async — true; 
dsoOriginal.XMLDocument . lLoadXML( 
dsoCourses .XMLDOocument . xml ) ; 
§ 


A DOMDocument objektum xml tulajdonsága visszaadja a 
benne található XML dokumentum forrását, a loadXML me- 
tódus pedig betölti és értelmezi a dokumentumot. 

Nekünk most csak a szorosan vett adatok kellenek, amelyek 
a dokumentum szerkezetének megfelelően egy fára vannak 
felfűzve. Ennek a fának a gyökeréhez a DOMDocument ob- 
jektum documentElement tulajdonsága vezet el: 


var objCoursesRoot - objCourses.documentElement; 


Így a courses elemnél járunk, amely alatt az összes csomó- 
pontot ki akarjuk irtani, mert oda fognak menni a megszűrt 
csomópontok. Az egyszerűség kedvéért nem végigmegyünk a 
courses összes gyermek csomópontján, és egyesével kitöröl- 
jük őket, hanem kicseréljük a feltöltött elemet egy üresre: 


//Itt az eredeti doksi... 

var objOoriginalCourses - //IXMLDOMDOocument2 
dsoOriginal.XMLDOocument ; 

//És annak a gyökere. 

var objoriginalCoursesRoot - //IXMLDOMNode 
objoriginalcourses .documentElement ; 

//Generálunk egy üres gyökérelemet, 

//azaz átmásoljuk az eredeti gyökérelemet 

//a gyerek elemek nélkül (parameter: false). 

var objNewRoot - 


objoriginalCoursesRoot .cloneNode( false) ; 


Most el kell végeznünk a szűrést egy jólirányzott XPath ki- 
fejezéssel: majd végig kell mennünk a szűrt listán, és 
felépíteni egy új XML dokumentumot: 


objoriginalcourses.setProperty( 
"SelectionLanguage", "XPath"); 

var strPathFilter - 
"course[containsítitle, "" 4 

strCourseFilter t ""))"; 

var objFilteredLlist - //IXMLDomNodeList 
objoriginalCoursesRoot.selectNodes ( 
strPathFilter); 

var objTempNode; //IXMLDOMNode 

objTempNode - 
objFilteredList.nextNode( ) ; 

while (objTempNode !-— null) 

( 

objNewRoot .appendChild( 
objTempNode.cloneNode(true) ) ; 

objTempNode -— 
objFilteredList.nextNode( ) ; 
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Utolsó lépésként kicseréljük az eredeti gyökeret az újon- 
nan felépített, szűrt gyökérre: 


objCourses.replaceChild( 
objNewRoot, 


objCoursesRoot) ; 


Ennyi. Elsőre talán bonyolult, de az érdeklődőknek min- 
denképpen ajánlom, hogy menjenek el az [1] címre, mert 
ott a teljes forrás egyben, bőven kommentezve megtalál- 
ható. A végeredmény pedig (némi plusszal, ami a web-es 
verzióban megtalálható) : 








IS] 
Taztolyazrióá [ Tazdolyam címe Előadó 
1905 festo TSA Based Web Appbsana TT [iőoczó Zao] mol séczodjnetacademia set 
I ( ] 
FBT [Ea] 1 Teesteta 
couwrsefcontainattátte, "Web al 
[mez Ir esaz 





Keresés XSLT-vel 

Ebben az esetben a vezérfonalunk az lesz, hogy készítünk egy 
sablon XSLT transzformációt, ami szűrni képes a forrás XML do- 
kumentumot. A konkrét kereső kifejezést beleszerkesztjük az 
XSLT-be, és végrehajtjuk a transzformációt, ami a másolat do- 
kumentumból legenerálja a szűrt dokumentumot. 

Az XSLT transzformációt - lévén, hogy ő is egy XML doku- 
mentum - egy XML szigetben helyezzük el: 


£xml id-"dsoXSLTransformation"5 
c?xml versionzc"1.0" encoding-"ISO8859-2"?5 
€xsl:stylesheet versionz"1.0" 
xmlns:xs1l-"http://www.w3.org/1999/XSL/Transform"5 
£xsl:template match-z"/"5 
courses 
£xsl:apply-templates select-"courses" /5 
£/coursesz 
£/xsl:template2 
£xsl:template match5s"courses"5 
£xs1l:copy-of select- 
"course[containsítitle, keresokifejezes)]"2 
£/xs1l:copy-of5 
£/xsl:templates 
£/xs1l:stylesheet2 


£/xmi: 


Ez a rövidke XSLT transzformáció a courses alól kimásolja az 
alatta levő összes course elemet, amelyre teljesül, hogy a tit- 
le elem értéke benne foglaltatik a keresőkifejezésben. 

A transzformáció végrehajtása előtt már csak egy dolog 
hiányzik: a keresőkifejezés helyébe be kellene csempészni 
a paraméterként kapott keresendő szöveget. Mi sem egy- 
szerűbb, ha van DOM-unk! 

Az XSLT dokumentumból kiválasztjuk az xsl:copy-of elemet, 
és annak a megfelelő módon átírjuk a select attribútumát. 


function SearchCourse(strCourseFilter) 
jé 

var strFilter; 

//Összerakjuk a kereső kifejezést. 


strFilter - "course[containsítitle, 
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4 strCourseFilter t "")])"; 
//Ebben lesz az XSLT. 
var objTransformXML - 
dsoXxSLTransformation.XMLDocument ; 
//KkKiválasztjuk a módosítandó elemet. 
var objCopyNode - 
objTransformXML.selectSingleNode( 
"//xs1:copy-of"); 
//Módosítjuk az attribútumot. 
objCopyNode.setAttribute("select", strFilter) 


Már csak transzformálnunk kell, és az eredményt visszatöl- 
teni az eredeti XML szigetbe: 


var strXMLTransformed; 

//Itt képződik a szűrt eredmény. 
strXMLTransformed -— 
dsooriginal.XMLDocument . trans formNode ( 
dsoxXxSLTransformation.XMLDocumen ) ; 
//Visszatöltjük, hogy megjelenjen az 
//eredeti adatforrásban. 

dsoCourses . XMLDocument . LloadXML ( 


strXMLTransformed) ; 


Az utolsó két utasítást helyettesíthetjük eggyel is, a trans- 
formNodeToObject metódus felhasználásával: 


//Alternatív transzformáció. 
dsoOriginal.XMLDocument.transformNodeToobject ( 
dsoXSLTransformation.XMLDocument , 
dsoCourses . XMLDocument ) ; 


Lássuk az oldalt működés közben [1]: 


CEE 


FTazolyamkóá[  Tadfolyam cime 3 


] 
haz JEGsgszdsmezg ösi Eng TAL SZAZELT fe szelesnczeluetscndema NET 
J 











za 


(Ejöse TIT ésmeer 





Azért ez egyszerűbb és átláthatóbb lett, mint a tisztán DOM- 
os megoldás, mert nem keveredik a DOM-ot kezelő kód és ke- 
resés logikája. A kulcsszó: XSLT [2]. Érdemes tanulmányozni! 


Zárszó 

Megtanultunk ügyféloldalon XML adatokat megjeleníteni és 
transzformálni. De mi lesz az XML-t nem értő böngészőkkel? 
Nekik már nem is jár XSLT? Dehogynem, csakhogy nekik a 
kiszolgálón kell elvégezni a transzformációt, így már csak 
HTML tartalmat kapnak. Nem lesz interaktív, viszont ki tud- 
juk használni az XSLT-ben rejlő lehetőségeket. Júliusban. 


Soczó Zsolt 
MCSE, MCSD, MCDBA 





Lise LdT3 NETAN 1ETI 
[11]: http://technet.netacademia.net/feladatok/xml 
[2]: XSLT rerefencia http://www.w3.org/TR/xslt.html 
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Lehettem vagy 8 éves, amikor a TV-ben először láttam Mar- 
co Polo történetének egy feldolgozását. Ki tudja miért, 
megragadott az a rész, amikor az Ázsiából hazatérő főhős 
lelkesen mutogatta a velencei kalmároknak a magával ho- 
zott papírpénzt, akik azt erős szkepticizmussal fogadták, és 
értéktelenségét bizonyítandó, elégették. Történt mindez a 
XIII. század végén. Hasonló gondolatokat ébresztett ben- 
nem nemrég egy ausztrál ismerősöm beszámolója, miszerint 
valahol nem akarták tőle elfogadni a műanyagból készült 
ausztrál dollárt. Történt mindez a XXI. század elején. Miért? 
A pénznek rengeteg fajtája létezett és létezik, a kagylópénz- 
től, mint legősibb árupénztől, a nemesfémpénzen keresztül, 
napjaink modern pénzhelyettesítő eszközeiig. De miért is 
fogadjuk el a 20.000 Ft-os papírpénzt? Mert tudjuk, hogy 
vehetünk rajta sok-sok csokit. A pénz nem több mint társa- 
dalmi megállapodás arról, hogy azt mindenki elfogadja fize- 
tőeszközként. Más kritériumoknak is eleget kell azonban 
tenni. Az angol-magyar üzleti szótár szerint , pénz minden 
olyan árucikk, amelyet a jog és a hagyomány általánosan el- 
fogad fizetőeszközként, értékmérőként és kincsképzőként." 
A pénz egyre kevésbé kézzelfogható, sokan alig tartanak maguk- 
nál, és pénzügyeiket, beleértve ebbe az édességboltban való vá- 
sárlást is, bankkártyával intézik el. Ez mind szép és jó, de a vá- 
sárló szemszögéből felmerülhetnek gondok, hiszen a kártyahasz- 
nálat nem névtelen, azaz teljes mértékben nyomon követhető. 
Az internetes kereskedelem jóvoltából a weben is rendelhe- 
tek csokit, megadom a kártyaszámom, az árát levonják, majd 
kiszállítják. Azonban a kisösszegű bankkártyás fizetések nem 
kifizetődőek sem az eladónak, sem a banknak, s névtelensé- 
get sem biztosít számomra. Hogy nézzen így körül nyugod- 
tan az ember egy webes erotikaszalonban? Ide bizony kész- 
pénz kell, (még ha elektronikus is), annak ugyanis nincs sza- 
ga, amely nyomravezethetne bárkit. A bankkártya büdös. 


Elektronikus készpénz? 

A Microsoft egyik kutatója, Yacobi, ezen a kiaknázatlan te- 

rületen évi 30 milliárd dollárt szimatol. Ez csak töredéke a 

kibertér teljes forgalmának, mégis szép szelet a tortából, ha 

valakinek sikerül kihasítania. 

Az e-cash több műszaki megoldást is kínál. A kiszolgálóol- 

dali tárca (wallet) egy távoli kiszolgálón tárolja az ügyfelek 

pénzügyi adatait. Földrajzi helyzetét tekintve ez praktiku- 

san az a hely, ahol az ügyfél a leggyakrabban intézi üzleti 

ügyeit. De lehet a tárca ügyféloldali is, amelyet a benne lé- 

vő bizalmas adatokkal egyetemben ott tarthatunk, ahol 

akarunk, például az otthoni számítógépen, noteszgépen, 

palmtopon, intelligens kártyán stb. A lényeg az, hogy sen- 

kire sem kell bízni a bizalmas adatok kezelését. 

Az ügyféloldali tárca lehet érme vagy egyenleg típusú: 

"0 Az egyenleg típusú megoldás olyan bankjegyhez hason- 
lítható, amelyen az összeget le lehet radírozni, és újat 
írni rá. Vásárlásnál sosem adom át, hanem a boltossal 
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az e-cash? 


szép egyetértésben kiradírozzuk a rajta szereplő össze- 
get, és felírjuk a vásárlás utáni maradékot. 

"B Az ,érméket" egy erre jogosult pénzügyi intézmény ál- 
lítja elő, pontosabban sorozatszámmal és digitális alá- 
írással látják el az értékjegyeket, ami garantálja érvé- 
nyességüket és egyediségüket. Ily módon különböző 
címletű ,bankókat", váltópénzt állíthat elő a kibocsátó 
szerv. Az e-érméket a vásárláskor , kivesszük" a pénztár- 
cából, és ,betesszük" a boltos kasszájába. 

Eddig egyszerű, de mi van a gyarló emberekkel? Lopás, hami- 
sítás és csalás mindig lesz amíg világ a világ, tehát valahogy 
védekezni kell. Az informatika világában mára megtanultuk 
tényként elfogadni, hogy százszázalékosan biztonságos rend- 
szer nem létezik, legfeljebb törekedhetünk arra, hogy minél 
jobban megnehezítsük az ellenfél dolgát. Az összes tranzak- 
ció ellenőrzése kivitelezhetetlenül drága, Yacobi módszerével 
azonban megjósolható, hogy részleges eseménynaplózásnál 
mekkora az a legnagyobb öszszeg, ami az egyes tárcatípusok- 
ból ellopható. Az egyenleg típusú e-pénznél ez exponenciáli- 
san nő, de az egyedi azonosítóval ellátott érmék feltörésével 
nem lehet ekkorát kaszálni. 

Yacobi kutatótársai, Kuch és England már kísérleteznek egy 

e-cash rendszer létrehozásával. A következő életszerű ese- 

teket vizsgálják: 

"0 Kisértékű vásárlások az Interneten: például, egy hírma- 
gazin weboldalának látogatója rákattint a kiválasz- 
tott cikk aktív hivatkozására, és néhány forint ellenér- 
tékért azonnal elolvashatja. 

"Anonim vásárlás az Interneten, mivel a vásárlók egyre 
gyanakvóbbak, és félnek attól, hogy a bankkártyaszá- 
muk illetéktelen kezekbe kerül. 

"0 Vásárlás rendhagyó eszközökkel: az ügyfél a tárcáját 
tarthatja például egy Windows CE-t futtató palmtopon, vagy 
egy intelligens telefonon. Fizethetünk úgy, hogy a palmtop 
és az árusító automata infravörös jelekkel rendezi le a dol- 
got, de úgy is, hogy a telefonba pötyögünk be egy titkos 
kódot a jegyrendeléshez, miközben épp a moziba tartunk. 

Az üzleti élet átalakulása új pénzformákat kíván, amelyek ren- 
delkeznek a pénz összes ismérvével, de felhasználásuk az azo- 
kat éltre hívó gazdaság területére korlátozódik. 
Az e-cash a maga nemében forradalmi, és ennek megfelelően 
nagy ellenállást válthat ki. Yacobi szerint a múlt hibáinak nagy 
tanulsága az, hogy a fontos pénzügyi intézményeket kell meg- 
nyerni az ügynek. Mert zseniális gondolat ide vagy oda, az e-cash 
pénzzé csak a mögötte álló társadalmi bizalom révén válhat, 
vagyis ha egytől egyig mindenki elfogadja. Ilyen meggyőző erőt 
azonban jelenleg csak a kormányzati felügyelettel és garanciá- 
val rendelkező bankok képviselnek. Bízzunk hát együtt! 


Zacco 
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K: Hogyan lehetne időlegesen letiltani a System File Protec- 
tion (SFP) szolgáltatást? Egyetlen fájlt szeretnék lecserélni a 
SYSTEM32 könyvtárban, de mindig visszajön az eredeti. 

V: Kezdjük azzal, hogy a SFP pontosan az ilyen jellegű fájl- 
csereberék ellen véd. Többszörös védelem van a Windows 
2000-ben a kritikus fájlok lecserélésének megakadályozásá- 
ra, ezek közül a SFP az egyik legdrasztikusabb, de ez érthe- 
tő, hisz egy hibás eszközmeghajtó (kernelmódban fut!) tel- 
jesen felboríthatja az operációs rendszert (kék halál). Má- 
sik védelmi vonalat képez az eszközmeghajtók digitális 
aláírása. Az ilyen meghajtók egészen biztosan átestek a 
Microsoft legszigorúbb tesztjein is (Kivéve, ha azzal a két 
tanúsítvánnyal van ellátva, melyet a Verisign oly ostobán vad- 
idegeneknek adott ki a Microsoft helyett — de ez egy másik 
történet.) A rendszerből kiszűrhetők a digitális aláírással el 
nem látott eszközmeghajtók SIGVERIF.EXE futtatásával. 


ES File Signature verification 





To help maintain the integrity of your zystem, critical fles 
have been digítaly signed so that any changes to these 
files can be auicky detected. 


Cfck Advanced to customize verification options. 
Cfck Start to check for any syztem files that are not 
digital signed. 





Close Advanced 


0 Digitális aláírások ellenőrzése... 





De hogy a kérdésre is választ adjunk: az egyik megoldás le- 
hetne a SFC /cancel parancs használata, ha működne. Azon- 
ban van megoldás, mégpedig a registry buherálásával: 


HKEY LOCAL MACHINENSOFTWAREMicrosoftWWindows NTV 
4, cCurrentVersionlWinlogon 
SFCDisable REG DWORD 
0: SFC működik. Ha baj van, kiabál 
1: SFC kikapcs. Következő indításkor rákérdez, 
hogy működjön-e 
2: SCF kikapcs a következő indításra. Magától 
visszakapcsolódik 


4: SFC működik. Nem kiabál 
Forrás: NetAcademia Windows 2000 lista 


K: Az NT4 SP6-ot szeretném újratolni, de nem megy fel a gép- 
re, mert azon fent van a High Encryption Pack. 

V: Az SP6-ból van külön High Encryption kiadás is. Ennek 
hiányában kézihajtánnyal juthatunk célba. 

1) Bontsuk ki a nem Hi-Sec service packot /x paraméterrel! 
2) Keressük meg az update alkönyvtárban az update.inf fájlt! 


tech.net! 





3) A [CheckSecurity.System32. files] szekcióban a Schannel.dll, 
Security.dilL, és Ntlmssps.dll bejegyzések elé tegyünk 
pontosvesszőt! 

4) Az update.exe-vel indítható a telepítés 

Forrás: NetAcademia Windows 2000 lista 


K: Odalett az operációs rendszerem. Ez még nem lenne baj, de 
újratelepítettem, és az új példánnyal nem tudom elolvasni az 
EFS-sel titkosított fájlokat. Mennyire reménytelen a helyzet? 

V: Az attól függ. Az EFS titkosítás egy régi, már nem léte- 
ző felhasználó publikus kulcsával készült ugyan, de minden 
EFS fájl visszaállítható a titkosításkori Recovery Agent (RA) 
privát kulcsával. Tehát a visszaállíthatóság annak függvé- 
nye, hogy fellelhető-e az RA privát kulcsa. 

A kulcsokról lásd bővebben az [1] címről letölthető PPT mel- 
lékletet, mely részletesen elmagyarázza a titkosítás folyamatát. 


ETETETT EKET ETT ETET NAT ETET 


DUPLA KV 
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A titkosítás menete 


Majd titkos Han k 
jár 
zést 


DES kul 


Módosítás nélkül szabadon terjeszthető! 


0 2001, NetAcademia Kft 








I [8 Unknown zone 


a Az [1] címen található animált efs.ppt egy mozzanata 


Az RA személye alapértelmezésben a helyi Administrator, il- 
letve tartományi tagság esetén a tartománybéli Administ- 
rator! A különbség lényeges: míg a helyi Administrator pri- 
vát kulcsa valószínűleg megvan a merevlemezen (hacsak 
nem formáztuk le a kötetet, de arról volt szó, hogy megvan- 
nak az adatok, tehát nem formáztuk le), addig a tartományi 
rendszergazda privát kulcsa tuti, hogy nincs meg lokálisan, 
hisz csak a publikus kulcs kell a DRF kitöltéséhez - a privát 
kulcs valahol a rendszergazda nadrágzsebében lapul. 

Tehát a visszaállítás ,kulcsa", hogy meglegyen az egyik pri- 
vát kulcs. Érdemes az Administrator jelszavára hajtani, hisz 
az az ÖSSZES titkosított fájlt el tudja olvasni - lévén ő a 
RA. A helyi rendszergazda kulcsa megszerezhető, ha meg- 
van még a profilja. Abban csücsül ugyanis a privát kulcs - 
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DUPLA KV ?7 DUPLA KV 

ha csak ki nem exportálta valaki flopira. Már csak azt kell elér- 
ni, hogy a régi Administrator profilját az új Admin , vegye ma- 
gára". Ezt könnyedén elintézhetjük egy harmadik felhasználói 
fiók igénybevételével, amely oldalról ,betolja" az új Admin 
alá a régi profilt. És - elvileg — kész! Nyílnak a doksik! 
Forrás: NetAcademia Windows 2000 lista 


K: Windows 2000 Professional alá újabb processzor került, de 
nem veszi észre. Ugyanúgy kell átállítani, mint NT4 esetén 
(ResKit UptoMP.EXE) ? 

V: Nem. Maga az eljárás hasonló, és a cél is ugyanaz, vagyis 
a HAL kerül lecserélésre, de ez ma már nem tiltott/tűrt 
funkció, hanem a beépített Device Manager használható. Az 
alábbi ábrán a kattintgatásokra előbújó bűvészek és varázs- 
lók igazi arca látható: 


[Aton ven 29 6slam HESTBSST TB 


od 








ar VórrDse  N71471999 
és Dévavesan AZT 

5 ön Digtal Sára Mázosat Wérdoser Z000 Pitásher 
2 ag 


9 To vimmdetsás about tha övén főst losded lev tás derisa, elek Déver 
5 Detalz To uriratal tha dííver fdez har thin devon, cáck Unrotal To uzdate 
tbe divat Hes foz in device, ckck Ugdae Dover 






Welcome to the Upgrado Device 
Driver Wizard 


This mizatd halon you vogada a devon átver lar a 
harónare devtse 









Select a Device Di 
"Whuch árva do vas mart to rulal tar b eves? 





felre tte maruáachant ad mdel al ya harátnarn derén azd Ben elek Nat lyan 
hava a dík that contans the díva you want la nutal, cíck Have 


9 Uni to Multiprocessor 


Értelemszerűen az egyprocesszoros ACPI driver helyett az 
ACPI Multiprocessor PC választandó, míg ha valakinek Stan- 
dard PC az eredeti meghajtója, azt MPS Multiprocessor PC- 
re kell cserélni. A keresztbe cserélés halálos! 

Forrás: NetAcademia Windows 2000 lista 


K: Szeretném összenyomni az SOL Server amúgy üres tranzak- 
ciónapló fájlját, de hiába shrinkelem, nem megy össze. 

V: Bizony nem! Az SOL Server a tranzakciónaplót körkörösen 
használja. Ha az a kevés adat, ami éppen benne van, pont a 
logfájl végén található, akkor mindaddig nem megy össze a 
fájl, amíg ki nem kergetjük onnan az aktív részt. Ezt némi ak- 
tivitás magától megteszi, de mi magunk is irkálhatunk és roll- 
backelhetünk dummy tranzakciókat, hogy túlforduljon a log. 
Abban a pillanatban, amint az utolsó aktív tranzakció is kifut 
a fájl végéről, a log a kívánt méretre rogyik össze. 
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Az, hogy egy adott pillanatban a log melyik része aktív, a 


USE adatbázis 
Go 
dbcec loginfo 


go 


paranccsal nézhető meg. (Ahol a status-2, az a log darab- 
ka aktív.) 


Ha az adatbázisnak csak egy adat- és egy logfájlja van, ak- 
kor a legegyszerűbb megoldás: 
1) sp. detach db "dbname" 
2) átnevezzük a logfájlt 
3) sp.attach single file db Odbname - "dbname, 
4 Aphysname - "adatfájl (path-szal együtt)" 
4) ekkor az SOL Server készít egy új logot 
5) ha minden OK, a régi, átnevezett logfájl törölhető 
Forrás: NetAcademia SOL Server 2000 lista 


K: A Command Prompt felokosítására van valamilyen módszer? 
Állandóan a Command Promptban állok a PING, IPCONFIG és 
hasonló parancsok miatt, és jó lenne, ha a standard felnyíl 
mellett egyéb kényelmi funkciók is elérhetők lennének, mint a 
jó öreg DOS-ban... 

V: A Windows 2000 parancssorát a CMD.EXE adja. Ennek mint- 
egy ezer kapcsolója közül (érdemes egyszer megnézni a CMD /? 
outputját) a /F:on egy nagyon hasznos kényelmi szolgáltatást 
kapcsol be: a parancsok a fájlok és könyvtárak első néhány 
betűje alapján egyetlen billentyűleütéssel kiegészíthetők! 

"0 fájlnevek kiegészítése: CTRL--F 

"0 könyvtárnevek kiegészítése: CTRL--D 

Forrás: NetAcademia Windows 2000 lista 


K: Ha minden patch fent van a gépen, és minden jog halál 
szigorú, kell-e félnem a hackerektől? 
V: Természetesen! A NetAcademia Security listán hetente jelen- 
nek meg írások újabb hackertrükkökről. Hacking is easy — külö- 
nösen egy magára hagyott gép ellen. De lássunk konkrét példát: 
az elmúlt héten kapott valaki az FIPRoot könyvtárába messze 
tájakról egy ASP lapot. A tüzetesebb vizsgálat kiderítette, 
hogy ebben egy olyan VBScript lapul, ami kilistázza a lemez- 
egységeket. Ámde az FTPRoot nem futtat ASP-ot, hacsak: 

"0 véletlenül és felelőtlenül nem állítjuk azonos könyv- 
tárra a web és az FTP szolgáltatásokat, és ráadásul en- 
gedélyezzük a Scriptek futását, vagy 

"0 mégsincs fenn minden patch, így Hacker Henry a fájlt 
tovább tudja másolni az IIS alá a közismert (és réges- 
rég befoltozott) CMD trükk segítségével... 

Forrás: NetAcademia Security lista 


A cikkben szereplő URL-ek: 
[1] http://technet.netacademia.net/feladatok/ppt 





tech.net! 


A ,tech.net magazin Brainstorm" a Dupla KV rovathoz 
hasonló, ám a személyes kérdésfelvetést és vitát is le- 
hetővé tevő rendezvény, melynek célja: 


s az elsőre talán ismeretlen technológiák 
élő bemutatása 

s a cikkekhez kapcsolódó kódok 
megírása/kipróbálása 

s a terjedelmi okokból kimaradt 
információk átadása 


E magazinnal együtt a rendezvényre érvényes belépő- 


jegyet minden előfizetőnkhöz eljuttattuk. 
További információk a belépőjegyen olvashatók. 


Várjuk Önöket a 
NetAcademia Mesterkurzusokon 


GYE ÁBANZUILA 


Vaal 





(Bár belépőjegyet adtunk, ez a tény önmagában nem biztosítja helyét a rendezvényen. A jegy célja előfizetőink elsődlegességének biztosítása, de a korlátozott résztve- 
vői létszám (100 fő) miatt a regisztráció kötelező. Jelentkezzen, amíg nem késő!) 





unNet app 
512: KkDIt/SeE€-OS 
LD12W sziím im etrikús 
forgsalomfüggetlen 
csatlakozás 
az Internetre 


; havi 35.000 tért 


Hungarian 
Netwocks 





Tel: 06-40-hunnet (486-638) 











(no limits) 








! 


§ Elosztott 
A alkalmazások 
"" fejlesztése, 


Ld 





Tanfol 5 KEL rolZ ualole 


Hi he) 27 LV 





íj 
KEN 
21 
; 


A tanfolyamkódok megfejtéséért és 
" további információért látogasson el honlapunkra: 


http:/ / www.netacademia.net 
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